Supply chain software companies are providing extensibility as part of their offerings. With the concept of extensibility, software vendors are providing the ability to “outsource” certain logic to a different system via interfaces, typically APIs. For example, once the product is picked in a vendor WMS, custom logic using an API may determine the shipping container. For a complex supply chain, there are many such examples where ‘extensibility’ has been exploited to achieve specific business needs. This method is a massive improvement to previous models that required full code changes, which usually had long lead times, high cost, and increased risk during deployment.
However, this process brings a new challenge for the customers of these extensible products: how do I manage the development of these integrations while keeping up with ongoing configuration and defect resolution? One answer is leveraging the agile methodology.
Bringing the Practices and People Together
Agile development practices have been around a while and are commonplace in software providers’ teams. The process of batching work, creating iterative plans, estimating level of effort, and constantly prioritizing a backlog have allowed technology companies to decrease time to market and be more adaptable to changing landscapes. However, it is less common in companies that purchase and use the vendor created software, even when the technologies have extensive configuration needs. Effective agile product management of extensible supply chain technologies can accelerate speed to deployment for internal initiatives, driving critical business value exactly when it is needed.
Knowledgebase on agile methodology is publicly available, so I will focus on key lessons learned from my experience in using agile methodology in supporting supply chain technology, including vendor software and custom products.
Creating Your Agile Supply Chain Playbook
In a previous blog post, I talked about the benefits of a network standard for supply chain technology, having that easily repeatable approach to standing up new facilities or nodes. Having the agile approach to setting up a new site, both in configuration and development, will provide incremental value each time it is repeated. Because every iteration of a site set up would be defined in epics and stories, detailed with dependencies and attachments, paired with deployment schedules, and finally tracked alongside production defects, you will automatically have a “new site” playbook with deep insight.
Additionally, as you bring in new types of work, such as API development paired with in-house logic, you will quickly understand exactly what you need to support that type of deployment. New enablement of functionalities will quickly become a list of tasks to complete from start to finish, in the correct order, without having that knowledge be tribal.
This playbook, exportable and ready to copy, would provide immediate estimates on the number of resources needed, the steps to be taken and in what order, the pitfalls to watch out for, and ultimately the most feasible timeline. Which brings me to my next point…
Accurate Estimates for Development and Deployment
Agile methodology forces the business partners and developers/configurators to adhere to a few key practices.
First, creating a sprint, which is a timeframe where the team is given a list of tasks to complete, and the progress and completion are being tracked inside the sprint.
Secondly, the team must assign a value (aka ‘points’) to a piece of work that represents the level of effort. Points can range from being an hour’s worth of effort, or a day’s worth, but should remain consistent to gather the critical insight.
Lastly, at least for this context, is the continuous prioritization of the work in the backlog. As a business needs change, new projects or opportunities arise, and defects pop up, holistic prioritization of tasks keeps the team working on the most impactful development. And prioritizing all the work from multiple channels prevents the common conundrum: “when everything is a priority, nothing is a priority”.
Let us now explore some of the applications these two practices enable.
Leveraging Sprints and Points for a Large Supply Chain Engagement
Say you have a new DC coming up, and the last site took 50 points of work to complete. If the team historically completes 10 points per 2-week sprint, you could reasonably assume they need 10 weeks (5 sprints) to complete the work. Furthermore, if you have the same team working on priority issue support for existing sites, and that usually takes up 2 points per sprint (10 points for support over 10 weeks), you can expect the team to need 12 weeks. It becomes a simple math problem.
Applying an Agile Approach in Smaller Scale Opportunities
Another example, if you are introducing a new piece of automation and the technical development will take 4 weeks, however, the physical commissioning of the machinery will take 6 weeks, you can spread the work out so that the team can pick up a high priority 2-week optimization project that adds value to other areas of the site while they continue to support the automation enablement. This approach ensures continued maximum throughput of the team that maximizes immediate value.
This continuous prioritization forces the business representatives to consider the outstanding work of all types, making sure that expectations are clear, bottlenecks are identified quickly, and the changing landscape of the business is considered in real-time.
Continuously Learn and Improve
Overall, the implementation of agile methodology, along with any one of the myriad of products out there to track work in the agile style, can build a repository of historical estimates and data on what is needed for any style of change, who is needed, the time required, and the dependencies or pitfalls to keep in mind. All these pieces of knowledge are required for a smooth inclusion of development, especially APIs with configuration dependencies, into the existing supply chain technology teams. Building this practice, along with appropriate support systems, can turn the art of building new sites or capabilities into a practical science based on reliable, historical data.
For more information about how to implement an agile methodology for supply chain engagements in your organization, reach out to our team at info@bricz.com.
Contributor: Jon Brashears, Senior Manager at Bricz