It’s no secret that project management impacts efficiency and efficacy. But how do you know what development methods are best for your team?
In this blog post, we’ll cover Agile and Waterfall methodologies, discuss the pros and cons, and help you determine which to choose for your industrial automation projects.
Jump to:
As you know, industrial project management is no walk in the park. You’re managing a team of engineers, reporting requirements, multiple servers & machines, and traceability requirements, just to name a few.
The most common methodologies, Agile and Waterfall, each have their strengths and weaknesses. And despite what scrum advocates will say, there is no “one size fits all.” In fact, choosing the wrong method for a project can cost integrators thousands of dollars.
Waterfall is the first and most common project management methodology in this industry.
Waterfall project management is sequential and chronological. In this approach, projects follow these predetermined steps:
Each step must be completed before starting the next, and work is planned and tracked using a Gantt chart or similar tool. In Waterfall, key performance indicators (KPIs) are Schedule, Scope, Quality, and Budget.
To explain how Waterfall works, let’s say you are managing the build of a house. The homeowner already knows what they want to build and has blueprints. You have the location, construction team, materials, timeline, and budget.
Because building a house is very linear, you can plan almost everything in advance based on your experience. Elements are brought in one by one, from surveying the land to putting final touches on the decor. Relatively little is unknown.
This process is exactly what you do with Waterfall project management. You gather all the information in advance and plan accordingly.
Laying out the project in advance means a few things:
Once the project is clearly defined, this planning method can work well, even if new resources join the project midway. The project timeline and tasks will be so well-documented that introducing new people tends to be straightforward.
Agile project management evolved in response to difficulties in handling complex, dynamic projects. In 2001, project management professionals created The Agile Manifesto. It identifies 4 central values (and 12 principles) which lay the foundation for what Agile is today.
Technically, Agile is not a methodology in itself. There are no steps outlining how to finish a project from start to finish. It’s not software. Agile project management is a set of practices that promote adaptive planning, iterative development, quick delivery and continual improvement.
Instead of in-depth planning at the beginning of the project, Agile methodologies are open to changing requirements and encourage constant feedback from stakeholders. The client should have frequent and early access to developed work so that they are an active partner.
The entire workload is organized into a backlog prioritized by importance. Rather than creating a set schedule, the project is “time-boxed” into phases called sprints. Each sprint has a set duration (usually in weeks) with a running list of deliverables planned at the start of the sprint.
As work is completed, it is reviewed and reevaluated by the project team and the client. The goal of each iteration is to produce a working product.
Since there are no fixed phases or rigid requirements, an Agile project plan gives your engineers more freedom to experiment and make incremental changes. This is great for creative projects and projects where the end goal is more unknown. And since there is constant communication with the client, project failure is unlikely.
While Agile is considered the umbrella framework, there are different ways it plays out in the real world. Scrum is an agile methodology that is built on the 3 pillars of transparency, inspection, and adaptation. It is meant for small teams and divides work into smaller goals that can be in accomplished in sprints. It provides specific guidelines to follow, including roles, responsibilities, and preset project meetings.
Roles:
Best Suited For:
Framework:
Step 1: Create the Product Backlog
The first step is to create the product backlog. The scope of the project is broken down into user stories and epics. Stories are short descriptions of functionality needed in the product, while epics are big-picture goals. Stories can be added to the backlog as a prioritized features list. Epics CAN be added to the backlog but first need to be broken down into user stories before they can be added to a sprint cycle.
Step 2: Plan Your Sprint
When you’re planning a sprint cycle (typically two weeks long), the Product Owner will choose the highest priority user stories to create tasks from. The team then chooses their tasks for the sprint and moves the work from the product backlog to the sprint backlog (the list of tasks to complete in the sprint).
Step 3: Meet for the Daily Scrum
The Daily Scrum is a 15-minute stand-up meeting where each team member talks about their progress and any issues that have come up during development. The team can also discuss changes that need to be made to the process. This scrum meeting happens daily during the sprint and helps keep the team on track.
Step 4: Refine the Backlog
At the end of each sprint, the team and Product Owner meet to make sure the backlog is ready for the next sprint. The team can remove user stories that aren’t relevant, make new stories, reevaluate the priority of stories, or split user stories into smaller tasks. The purpose of this refinement meeting is to make sure the backlog only contains items that are relevant and detailed, and that meet the project’s objectives.
Step 5: Review the Sprint
At the end of each sprint, the team reviews what they’ve accomplished. They talk about what went well during the sprint, what went wrong, and what they could do differently during the next sprint.
Since Scrum Team members are highly involved and there are no defined team roles, they need to have a lot of technical experience. These projects work best when the team commits to the daily Scrum meetings and remain on the team for the duration of the project.
Another popular Agile methodology is Kanban. Kanban is a framework that uses visual cues to show progress and delegate work based on available capacity.
Kanban was inspired by Toyota’s Lean Manufacturing practices. In the 1940s, Toyota implemented just-in-time production, stocking just enough product to meet demand. This improved efficiency and reduced waste by balancing supply and demand. Kanban operates on similar principles.
Roles:
Best Suited For:
Framework:
Like Scrum, it requires full project transparency and continuous communication between stakeholders and team members. It also encourages small, incremental changes to your current system.
But unlike Scrum, it does not require a specific timeline. Scrum is based on planning, sprints, process improvement, and releases. With Kanban, you can choose to do these activities on a regular cadence or whenever you need.
Scrum resists change, whereas Kanban embraces it. Scrum allows for some project flexibility, but the team has a rigid focus on the stories picked for each sprint. In Kanban, you can add or change stories as needed. A Scrum board is reset after each sprint. A Kanban board is used throughout the project.
Regardless of whether the Kanban board is physical or digital, its function is to visualize tasks, standardize workflow, and help quickly identify and resolve bottlenecks and dependencies.
A Kanban team focuses on the work actively in progress. When an item is completed, they pluck the next item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team because any changes outside the current work items don't impact the team.
While a Kanban board doesn’t have an explicit timeline, that doesn’t mean you can’t estimate project deadlines or completion. Cycle time is a key metric for Kanban projects. Cycle time is the time it takes to complete a work item – from the moment work starts on that item to delivery. It does not include the time tasks are waiting in the queue. By optimizing cycle time, teams can confidently forecast the delivery of work.
Both Agile and Waterfall approaches have their place in industrial automation. Waterfall’s biggest advantage is in, “measuring twice and cutting once”, planning well and sticking to it. Agile’s advantage is its flexible and incremental approach that adapts as time goes on.
When choosing a methodology, misconceptions may pop up when you start to challenge “how it’s always been done”.
For example, some project managers mistakenly believe Agile does not have a defined scope because features are not signed off on upfront. Remember that for industrial projects, you almost always MUST have big picture deliverables early on. But you continue narrowing in on these deliverables (and documenting them) through each sprint.
Another misconception is that any period can be called a sprint. There is no such thing as a long sprint. Longer periods deemed “sprints” tend to lack the built-in feedback loops which make Agile so iterative and flexible.
So, which one is better for industrial automation, Agile or Waterfall?
The answer unfortunately is, it depends. But I promise I’ll explain. It all comes down to the complexity of the project or what I like to call the CHONK LEVEL.
When it comes to picking a project management methodology, one of the first questions to ask is: How CHONK (complicated) is this project?
Disclaimer: This chart does not constitute as medical advice for your cat. Any similarity to actual cats, living or dead, is purely coincidental.
To accurately determine CHONK, there are four factors to consider:
The combination of these factors will determine whether Waterfall or Agile is more appropriate. Agile thrives on complexity. The higher each factor is, the more likely it is that Agile is the right choice.
The first factor to consider is project size. If your project requires a large team (on your side and/or the client’s side), then chances are it’s complex. Project complexity can also be judged by the number of systems the project affects, the number of servers or how many machines are involved.
To show how massive a project can be, one project we were involved in saw:
This project required Agile methodology and Agile-friendly tools to keep everything and everyone in check.
But not every project is a MEGACHONKER. Smaller projects are not as suited to Agile, because implementation requires too much operational overhead.
But project size is not the only factor.
The 2nd factor to consider is the number of unknowns. Unknowns include everything that is, well, unknown. Unknowns can include the timeline, the number or scope of features, and the number or types of systems involved.
An unknown could also be that the development team hasn’t performed this type of work before, which means that task estimations won’t be exact.
The more unknowns there are in a project, the more likely Agile is going to be a better fit.
The third factor is the number and quality of reliable benchmarks. Project benchmarks help keep the project on track and are good reference points along the way. Without benchmarks, it is harder to tell how far you’ve come and whether everything is going to plan.
If benchmarks are known and can be mapped out, then Waterfall is possible. If not, Agile is almost a must.
The final factor is the amount of customization needed for the project. How many deliverables are well-defined? How many still need to be explored? Custom features and deliverables that you’ve never been built before cannot be estimated with 100% accuracy. You can get close, but unlike standard features, you’ll need more wiggle room. The more customization is needed, the more likely Agile is going to be a better fit.
For even more nuance on project complexity, check out the chart below:
(This chart is based on the Stacey Matrix.)
From a strictly industrial automation perspective, we also find that different project types often lend themselves to either Agile or Waterfall.
Manufacturing Execution Systems (MES) projects help make better sense of production data. We can connect MES software to just about any plant floor equipment to provide real-time data and instant reporting straight from the source.
Best suited for: AGILE
From a DevOps perspective, MES projects tend to have more innovative features based on unique client requirements. So, we tend to use an Agile approach more often.
Supervisory Control (SCADA) projects improve plant monitoring and control. Clearly presented information, intuitive system controls, and clear navigation are the core of good SCADA/HMI programming.
Best suited for: WATERFALL
SCADA projects tend to be more standard, with specific ways of implementing them based on our industry experience. So, we tend to use a Waterfall approach more often.
Some projects are a combination of SCADA and MES or are another project type altogether. Depending on the situation, we might use Agile, Waterfall or a hybrid of the two. With these tools in your back pocket, you can find the method that works best for your project, client and team.
Imagine a perfect world, where everyone on a project has crystal clarity on what they should be working on, what their team is doing, and the overall progress against the project timeline.
Team members are well-resourced and know when and how to reach out if they need help. Quality checks are built-in to ensure total alignment with project requirements.
And above all, both your team and the client are satisfied with the final product and the experience along the way. Sound like a dream? It is closer than you might think.
At Vertech, we use both Agile and Waterfall based on the above factors. We also consider client expectations, project type, and previous work. Then we incorporate everything into our 5D method. Our tried-and-true management approach applies to both Waterfall and Agile projects and ensures communication is clear and clients’ expectations are fully met.
If the project is Agile, we'll also use DevOps to organize, test, and deliver development work.
DevOps is a technology development and delivery framework that combines development (dev) and operations (ops). DevOps helps people and processes work together - across departments – for efficient and predictable development.
Implement DevOps well, and your team can turn into a well-oiled machine with fewer mistakes and consistent, boring releases. It is important to take the time to develop your DevOps process before starting Agile project work or get an expert to develop it for you. We developed our process within Azure DevOps by Microsoft, but you can use any DevOps tool that works for your company.
Your team with good DevOps:
Key DevOps Benefits:
This is a super high-level summary, as we could write an entire blog just about DevOps. Learn more about DevOps here.
Hopefully, this article has shown how picking the right project management method can help keep your industrial automation project on track, on time and on budget. If you’ve just skimmed through this entire thing, here are the key takeaways:
Want to learn more about delivering a successful industrial automation project? Check out these other resources: