Over the last year, I have personally been involved with two e-commerce companies that used Agile software development and deployment approaches for their e-commerce sites requiring integration to both Enterprise Resource Planning (ERP) and Supply Chain Execution Systems (WMS).
Agile is a Project Management approach used primarily for product and software development. The approach is based upon iterative work cadences or “sprints” that build collaboration between cross-functional team members. For those of us who cut our teeth in manufacturing, think of Waterflow as manufacturing large batches of work in process inventory (WIP) vs. small batches of work in process inventory. We all know from JIT principles and Toyota Production Systems (TPS) techniques that small batches reduce variability and allow for agile shifts in production with the goal of meeting unpredictable customer demand.
You may presume I am going to jump on the Agile band wagon… Not exactly! Waterflow deployment approaches, on the other hand, are sequential in nature: design, build and test. The downside to waterflow is: 1) it is sequential, 2) the major steps take longer, resulting in increased variability between steps and 3) if you get the design wrong, the end product delivered could be wrong. The assumption by Agile disciples is that it is impossible to define 100% of your functional and technical requirements and that 80% is “good enough.”
Is one methodology better than other? The answer is no. Both methodologies are valuable with respect to implementing and integrating software applications and technology.
In the aforementioned projects, both were successful not because Agile was superior over Waterflow, but rather because the project managers for both projects brought a great deal of experience (15+ years) and defined what I refer to as “a common picture of success.”
Hidden Treasures of Advanced Warehousing
Make the most of Microsoft Dynamics 365’s Advanced Warehousing module and gain insight into the hidden treasures to unlock value.
However, both companies struggled at the beginning, rework was common, interdependent work flows between the e-commerce store front and the ERP were missed, and error resolution testing was an oversight. The fundamental challenge is that e-commerce solutions are built on open source code and/or on platforms compared to ERP and Supply Chain Execution solutions that are built on the concept of system configuration and data parameters.
It is important to describe the difference between software that requires systemic configuration and data parameter settings versus an open platform software solution. I like to think of an open architected software solution as if I were to provide a painter a brush, a pallet of paint colors and canvas and then said, “Paint away.” Compare this to software applications that are dependent upon system configuration and data parameter settings where the same “tools” are provided, but instead of an open canvas, the painter is constrained to a “paint by number” approach to create a predetermined end picture.
Therein lies the problem with Agile vs. Waterflow. You need to understand what type of software you are building, and/or deploying. I am of the opinion that is difficult to apply Agile methodologies to a solution architecture that is rigid and solid. In my last two projects, the e-commerce developers were using Agile and the Enterprise and Supply Chain Execution teams utilized Waterflow.
This definitely created conflict, and a very interesting dynamic occurred in the first six months of the nine-month project. The Agile e-commerce team was “sprinting” ahead with their back log folders and daily scrums, making fast and furious progress. However, the resulting perception was that the “sluggish” ERP and Supply Chain Execution team was behind schedule and holding up the nimble e-commerce team.
At the six-month mark of the project plan, the projects hit a critical intersection called, “end to end integration and user acceptance test planning.” Both projects had to stop and reevaluate their approaches. Why? First, because the requirements planning and definition that the Agile team completed was high-level (big brush strokes 80% fit). Second, the Waterflow team did a poor job communicating to the e-commerce team the sequence of events (prioritizing the back log folders). Third, no one was holding the “pigs” accountable for delivering the code on time. Fourth, scrums are not designed for the “chickens” to get into the detail and problem solve issues. It is assumed that detailed conversations about the design functionality are to be conducted outside the scrum, and this can be a bad assumption. And the fifth and biggest challenge was the lack of an integrated schedule that linked what Elli Goldratt calls, the “Critical Chain.” It is imperative that you have an integrated Project Plan.
Despite the challenges, both projects were successful. The lesson learned from my personal experience is the importance of ensuring that every project team member is versed in the implementation methodology. Regardless of the methodology being used, “the devil is in the detail.” You better understand the functional and technical requirements.
As a pilot, I know where I am going prior to taking off. I complete my pre-flight checks, I file a flight plan, I check the weather en route, and I have a contingency airport lined up in case of an emergency. I have a plan and I know where I am going.
Steering a critical technology project is much the same way. Regardless of whether your company uses Agile or Waterflow, you better define, plan and communicate where your team is going, or you may not safely arrive at your desired destination!
I look forward to receiving your personal anecdotes about your project methodology experiences.
