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.
BENEFITS / CHALLENGES
Benefits of Agile
- Ability to add new requirements throughout the process
- Regular intervals which demonstrate working solutions
- Continual improvement through team retrospectives
- Empowerment of team members, providing a stronger team morale
Challenges of Agile
- Can be less predictable from a time and duration standpoint due to potential requirements changes and evolution
- More effort required to facilitate communication across self-sufficient teams
- Potential for re-work if requirements addressed in earlier sprints did not consider requirements from later sprints
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.
- 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.
- 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.
- 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?.
"Even with quick 'time to benefit' claims, waterfall approaches are still the most prevalent methodology used."
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.
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.
Meet the Author
Brian Lewis is a Client Engagement Director at JBF Consulting. Brian has over 25 years of extensive experience in Transportation and Logistics. Brian has helped organizations with multiple processes such as procurement, trading partner collaboration, transportation planning/optimization, visibility, settlement and billing, and reporting and analytics. His experience spans across multiple verticals including Retail, CPG, High Tech, 3rd Party Logistics, Food/Beverage, Government, and more. He has delivered both domestic and international projects. Brian earned his BS in Business Logistics with a minor in Management Information Systems from Penn State University. Brian is a certified SAFe Practitioner.
About JBF Consulting
Since 2003, we’ve been helping shippers of all sizes and across many industries select, implement and squeeze as much value as possible out of their logistics systems. We speak your language — not consultant-speak – and we get to know you. Our leadership team has over 70 years of logistics and TMS implementation experience. Because we operate in a niche — we’re not all things to all people — our team members have a very specialized skill set: logistics operations experience + transportation technology + communication and problem-solving skills + a bunch of other cool stuff.
For more information about SAFe agile methodologies, please visit: https://www.scaledagileframework.com/