Agile, Waterfall, or Wagile – How Should You Implement Your TMS?

Transportation Management Systems have been implemented for decades now, and each implementation provides its own unique challenges. Software providers and system integrators have introduced their own implementation methodologies, often associated with catchy phrases and marketing materials to back them up. Largely those methodologies are waterfall based and realize the most benefit at the end of the project. 

With the evolution of cloud-based TMS solutions, providers are touting quick-to-benefit timeframes, in days and weeks instead of months and years.

Even with quick “time to benefit” claims, waterfall approaches are still the most prevalent methodology used. 

Agile on the Rise

In the last year we have  seen a rise in companies utilizing the Agile methodology.

This approach is typically used by organizations in their product management and development groups that are building solutions from scratch or building upon an existing code base. The application of Agile to implement commercial TMS systems is an approach that should be examined and evaluated for use for your TMS implementation. 

A Brief Overview of SAFe Framework and Agile Methodology  

It is not our intent to go into the methodology itself in detail, as there are multiple resources to learn the mechanics of Agile. Our goal is to give context to our experience in this implementation approach, especially as compared to traditional Waterfall techniques. A great place to learn more about Agile and the concepts is at SAFe 5 for Lean Enterprises.

Some essential concepts you should know about the Agile methodology are as follows: 

• The Agile methodology is a project management framework that breaks projects down into several small phases, commonly known as sprints. 
• The overarching principle of the framework is to iterate, delivering results sooner and providing incremental gains in functionality.  

• A recent Agile project that we participated in utilized the Scaled Agile Framework (SAFe). SAFe is a collection of principles, practices, and competencies for achieving business agility with a Lean-Agile mindset. 
• The driving force is the solution train, which defines which epics and features are to be delivered. 
• Epics may span across multiple program increments, while a program increment typically has 5-6 sprints. Sprints are 2-4 weeks in duration. The illustration below shows how program increment (PI) planning, performed across all teams, drives PI objectives. PI planning identifies specific features and stories to be developed for all teams. Each sprint ends with a retrospective, and each future sprint is also planned. At the end of all sprints within the PI, a retrospective called “Inspect and Adapt” is conducted to review what went well and what could be improved. PI planning is conducted again, and the cycle repeats with new sprints and new features to be developed. 

 

Overall, we did see promise in applying some of the principles of Agile to specific areas of the TMS implementation, and below are some of the key learnings we took away from our role on the project. 

Sprint Zero 

• Conduct one or more “Sprint Zero” for planning, discovery, and solutions design:
  
  Before we started any implementation work, time was spent discovering the as-is processes and finding the nuances that needed to be accounted for in the final solution. This provided key insights as to how we would need to configure the solution to support all business processes. 

Plan for Future Sprints 

• Features and functions will need to be revisited in future sprints: 
   
  A principle of the Agile methodology is to deliver workable solutions after each program increment has concluded—and working solutions may be expected even after individual sprints. For example, as you begin a TMS project in an Agile environment, you may be expected to deliver current master data immediately following the sprints for discovery and solution design. This may include carrier master, location master, and/or tariff and rate master data. 
   
  When you move into other functional areas such as load optimization, tendering, or freight payment, some decisions you made previously may have to be re-visited to align with downstream workflows. This expectation should be set ahead of time, so that early wins and functioning software can be realized sooner to provide excitement within the project, even if some changes are required to the working solution later. Project discovery and solution design in the first sprints should prevent any major disconnects when attempting to deliver working solutions throughout the project. 

Incremental Progress 

• While delivering functional solutions rapidly, you may need to progress through several sprints or program increments to fully realize value: 
   
  While it is good to show progress often as sprints progress, the fact is there are cases you cannot realize any value until all elements of the operational flow have been delivered. While it might be nice to have carriers and locations loaded to enable planning and load tendering, you may not be able to utilize this functionality until additional parts of the solution are completed. This often includes integration objects into host ordering, ERP, and financial systems. 

Coordinate Efforts 

• Typically, multiple scrum teams exist, and it is important to coordinate efforts across all teams: 
   
  During the project, we had smaller teams that were responsible for different aspects of the solution, and each team was self-organized and managed. We had a scrum team that had integration responsibilities, another team had master data, another team was responsible for load planning. Each team was expected to deliver value, but it was imperative for the scrum masters and product owners to raise concerns and issues that possibly impact other teams. When appropriate—and with a TMS implementation, it almost always is—cross-team coordination and decision-making must occur. 
  

Strength in Superuser Team 

• There is no substitute for a strong superuser team: 
   
  Superusers are vital to any TMS implementation. In the simplest terms, Superusers are the liaison between the business and IT. They must gain knowledge close or equal to the functional leads/consultants that teach them the solution. 
   
  It is key for Superusers to have some level of knowledge about all aspects involved with the solution deployment. They must be able to troubleshoot and resolve most issues and, when they cannot fix an issue, know the right people to contact in order to get it resolved efficiently. 
   
  In an Agile project, Superusers are often individual contributors on a team but need to be aware of the activities on all other teams, while also being capable of drilling into the solution and making necessary configuration changes. It is critical that knowledge transfer occurs among Superusers across teams and from the subject matter experts involved with the project. 
   
  For more on Superusers, feel free to check out Can a TMS Virtual Superuser be Your Super Hero?.

 

Pure Agile is not conducive to all aspects of a commercial TMS implementation. We believe Wagile, a combination of Waterfall and Agile may be a better approach.  

There are solid arguments that TMS projects should be implemented using a Wagile approach. Many tasks, such as master data gathering and clean up, rates/tariff loading, plus carrier and host integration can utilize sprints.

For more complex routing solutions, an Agile-based approach can not only speed up the process but generate a more robust optimization solution that saves time and reduces execution costs. 

However, there are other areas where a linear, waterfall approach may be better suited. For example, when determining how rates will be configured, a waterfall approach may be appropriate if you are also planning on performing freight audit and pay since rate configuration has an impact on the freight audit processes. 

The same concept may apply to reporting. While integration to a data lake may be “sprint worthy”, developing key reports may require data from carriers, so this would need to wait until integration of carrier status messages has been completed. 

Key Takeaways

In our experience, most successful implementation programs have a healthy mix of Waterfall and Agile approaches—it is critical to know when to deploy each approach. While Agile principles and practices are very well suited for software development, they are also applicable to the deployment of a commercial TMS solution, albeit in a more limited fashion than pure development projects. 

There are components of almost all commercial solutions that fit the Agile methodology well: integrations that require development, data loading and API builds, plus configuring business rules, both within the application and in middleware applications. Components of Agile can certainly work if you take care to continually have an eye on the overall solution and desired end state.  

If you are interested in learning more about our WAGILE experience or need support determining the right implementation methodology for you, we are here to help.

 

🔹 🔹 🔹 🔹 🔹 🔹

Subscribe to the The Digital Logistician

Sign up for our Monthly Email Bulletin

Follow the JBF Company page on LinkedIn

Download our white papers & ebooks

Read more articles our blog