“Never happen…” “Can’t be done…” “Too controversial…”
These were the comments an Agile team received when they floated an idea for a national Agile initiative to transform their organization’s inventory management workflow. It was an opportunity they identified in the course of their work as Agile practitioners.
Inventory management was a tightly controlled function of the business. And the Agile team suspected that any proposed change to the process would be met with resistance.
“Too risky…” “Never get buy-in…”
They were right.
The Scope of Inventory
These reactions were understandable. The service this organization provided was food services, and when it comes to managing perishable and non-perishable products, managers have to follow many federal regulations and corporate policies.
The financial scope of the inventory was also a factor. Nationally, Unit Managers controlled about $200 million in actual net inventory. And to manage that inventory at the level of control that leadership required, service teams nationally had to invest tens of thousands of hours of labor time.
But the process was manual and time consuming. Managers questioned the organization’s prescribed balance of value and control and complained that the process took time away from important activities like interacting with customers.
So the Agile team envisioned lightweight and efficient approaches to inventory management that will make life easier for managers and maintain the organization’s quality standards for food and expense management.
They just needed to convince Senior Leadership to authorize a project to develop those approaches.
The Current State
Corporate policy required that inventory is taken at least once per month. But Unit managers did it every week. The reason was that Division Leaders required weekly expense tracking, and the only way to document expenses every week was to conduct inventory every week.
So with the help of partners in the Finance department, the Agile team analyzed inventory data which they cross-referenced with their own value stream process maps to determine the labor investment of the inventory process.
The numbers were jaw-dropping.
The annual cost in labor hours to conduct inventory once per month was $2.4 million. But to perform the process every week, the organization had to direct an additional $7.2 million of labor resources.
When the Agile team presented these findings, Senior Leadership took notice. They never considered their operational demands in terms of how much was invested compared to how much value was produced. They regarded the frequency of inventory solely as a way to mitigate risk.
The Business Case
So the Agile team presented a vision of a new “product” that allowed Managers to track inventory weekly, but in quick and nimble ways so that cost of labor is reinvested in other higher value activities.
This new perspective of operations and value inspired Senior Leadership to consider the Agile team’s proposal. After some deliberation, they authorized a pilot.
A Daunting Challenge
The scope of the challenge was not lost on the Agile team. Even though they planned to apply an Agile framework to the pilot, the Agile “team” would have to be… unconventional.
In a simplified layout of Agile (Figure 1), the presence of a “customer” is at the front and back-end of the continuum.
- “Customer” perspectives define the value of the product.
- “Customers” (or Users) receive the product upon release.
- Sponsor(s) authorize the product.
- The Product Owner represents the business (and customer) during planning and development and approves Acceptance Testing.
- Self-organized Development Teams create the product.
- The Agile Team facilitates the framework to ensure its success.
Traditional Linear Agile Model
A Unique Agile Model
But for this pilot, everyone had a hand in defining value and designing the product. They also had a say in the definition of Done and the Acceptance Criteria.
So to put together the pilot teams, the functions and roles of a traditional Agile project had to be performed by eclectic mix of stakeholders (Figure 2). For example…
- Unit Managers and Sponsors define product value.
- Unit Managers develop the product.
- Unit Managers, Sponsors and other Stakeholders (such as Finance and Audit) approve Acceptance Testing.
- And the Agile team act as servant leaders but also had to assume some Product Owner duties such as guiding the backlog of work.
Agile to Agile Model
Agile to Agile
The Agile team’s plan was to leverage Agile techniques in new ways so that the pilot will succeed and Senior Leadership will authorize a national Agile deployment.
As the team referred to it, they were going to “use Agile to get to Agile.”
Here is how they did it:
The Agile team mapped existing processes to understand the value of every task in the inventory workflow. Partners in Finance helped the team model financial analyses from unit, accounting and audit perspectives. This empirical information formed the cadence of reporting and enabled collaborative and objective decision making.
- User Stories
The Agile team conducted Voice of the Customer interviews with which they wrote User Stories. These stories were the foundation of product development and defined deliverables.
The organization was large (over 100,000 employees) and was structured into business “segments” based on the industries they served (Healthcare, Universities, Government, etc.). As a result, each segment had its own requirements when managing inventory.
To address this, the Agile team scaled the pilot so that teams from each segment could develop a suitable configuration of the product and meet their own acceptance criteria.
- Minimum Viable Product
Despite Leadership’s approval for the pilot, their support was tenuous. So the Agile team planned to produce incrementally an acceptable minimal viable product that worked and inspired support for the next iteration of development.
- Iterations and Increments
Segment Managers developed “visual inventory” techniques to count and estimate the value of products on hand – as opposed to statistical counting and recording. Pilot teams repeatedly fine-tuned these approaches and trained their staff on the skills they would need to perform this process on their own.
To test quality, “Visual Inventory” data from weeks 1, 2 and 3 were compared to data from week 4 when the physical inventory process was done. If the data sets were consistent, the “visual inventory” process was working.
If there were discrepancies, the Agile team acted with total transparency and analyzed the process to determine root causes. The process was refined and developed again.
At the end of each monthly sprint, the Agile team demonstrated the new process with insights from Leadership, Operations and Finance with which they planned the next iteration.
The Agile team organized retrospectives to review the effectiveness of the pilot process. Managers from the segments shared their learnings, helping each other address challenges.
The retrospectives fostered an increasing sense of engagement and inspired confidence in Senior Leadership that these techniques had the potential to work across the organization.
- “Done” & Acceptance Criteria
The definition of “Done” was the domain of the Internal Audit group who had the authority to certify whether a new process satisfied the organization’s requirements for accuracy and reliability.
Acceptance Criteria was the domain of Unit Managers and Division Leaders. They determined whether a new process truly increased value and maintained quality expense management.
- Kanban and Lean
The Agile team trained Unit Managers to use Kanban Boards to track the flow and levels of their inventories. These were popular because Kanban boards easily communicated inventory levels and prompted staff to use a pull system for new product orders, optimizing the flow of materials.
After three months of successful testing, each pilot team settled on a solution that worked for their segment. Stakeholder groups such as Finance and Audit all approved. Segment Leadership as well came to support Visual Inventory as a viable replacement to the weekly physical inventory process.
With the pilot declared a success, Senior Leadership authorized an Agile roadmap to deploy the solution to 4,000 locations while allowing for process customizations based on local needs.
The solution was received with great enthusiasm: “Thank you so much!” “We love it!”
Three months after full implementation, the organization conducted an audit of the operational, labor and accounting CTQs (critical to quality measures). All segments reported that the quality of inventory management was constant or better than before. Labor productivity improved (valued at ~$4M per year) and food utilization increased.
It was quite a journey. The experience of transforming the inventory process taught the Agile team not to limit themselves to think of Agile purely as a project framework. Rather, Agile values and mindset can reveal opportunities to apply the framework in unexpected and innovative ways.
For this reason, it is worthwhile for Agile leaders to emphasize Agile values and mindset in their day-to-day work lives so that they may one day lead their organization away from “Good luck…” and on to “Great job!”
About the Author
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.