Since I often advocate for an Agile approach with POS System optimization clients, I find myself explaining what the Agile methodology is, and why it is optimal for retailers.
In a nutshell, Agile is a responsive method of project management (especially for software development) that provides regular and frequent delivery of results that emphasize real business value. There are three components here that emphasize the core value of this approach.
- Regular time intervals. Breaking work into consistent intervals of time establishes a working schedule and ensures that there is clear group focus on the goals that are committed within that period of time. It also prevents those specific goals from getting away from the team, becoming muddled or too big-picture.
- Delivery of business value. The goals for each time interval are focused around small chunks of work and each time interval must focus on goals that deliver business value. This prevents work for the sake of work or deliverables that cannot actually benefit the business in a real way. It means that the end of each time interval provides something that is ready to be used.
- Responsive priorities. Because the Agile approach breaks work into small chunks and the work pathway into manageable periods of time, it leverages a responsive framework. The ongoing creation, clarification, adjustment and re-prioritization of those chunks of work mean that at the end of each time interval, the next highest priority items are handled. Since work is deliverable after each time interval, assumptions can be tested with the work that is being regularly delivered and those insights are then factored back into the prioritization of the next work items.
Let’s explore a very simplified sample scenario.
A retailer wants to start tracking all the price-matching they do for competitor sales in their POS System. This will let them know how much money they lose to price-matching, on which items and categories, as well as with which competitors, among other things.
Luckily, their POS supports this with some features but requires some up front work that will mean this cannot be executed for about 3-6 months.
An Agile approach would ask what the most important information to collect first is, including what assumptions these priorities are based on. In this example, let’s say it turns out that determining how much money they are losing to price matching is the highest priority and an assumption is that a lot of customers do this.
The highest priority deliverable chunks are mapped by user stories (Note: I’ll be doing an upcoming blog post on User Stories) around delivering:
- the ability to identify transactions that contain any price-match occurrence
- the ability to identify the dollar amount discounted due to price-match
(The backlog would also contain additional items such as being able to identify the specific item being price-matched, being able to identify the competitor, whether it was an everyday price or flyer price, etc.)
So the first time-interval delivers item #1 and determines that actually, this happens quite often. Interestingly, though, it is done by a very small sub-set of the total shoppers. The second time-interval delivers item #2 and determines that the amount lost is actually pretty substantial on those transactions.
Before executing the next time interval, the retailer determines that our assumption that “A lot of customers are doing this” is actually slightly incorrect. It turns out it’s more like “A few customers are doing this a lot”. We’ve also learned that it’s hurting profit quite a bit when it happens. Factoring this with other business knowledge and collecting more data to validate, the retailer decides to shut down their price-matching program altogether. It turns out it costs money and doesn’t really do much for the business.
If the retailer instead decided on a full course of action in advance, they would have waited 3-6 months to discover this. In fact, they would be so committed to a pathway and assumptions that they might not even have stopped to consider this core data and validate those assumptions. They might have had a more junior employee tasked with actioning the data as soon as it became available, investing even more time, money and strategy.
While this is of course a simplified example, it helps to easily demonstrate how an Agile approach ensures the delivery of business-value and those frequent deliverables help validate and clarify next priorities.
It is also worth noting that Agile handles priorities associated with different issues simultaneously. In other words, in real life you might also be delivering completely unrelated bug fixes or new features associated with tare weights, or employee logins, etc. within the same time interval. It does not require you to commit to only one particular business initiative at a time. It just ensures you commit to work that delivers business value and can be achieved within the time-box.
While it might sound like a straightforward and even obvious technique, the truth is that the majority of development (and even process) in the majority of organizations follows the traditional “Waterfall” approach that plans all activities in advance and invests heavily in assumptions. While software development is increasingly moving away from the Waterfall development method, retailers would be wise to get ahead of this curve and benefit from the lessons of an industry that is built around getting something use-able in the hands of its customers as early as possible.
Retailers can’t afford to invest in false assumptions. This is a fast-moving industry where time and attention must be carefully budgeted to where the value is. So instead of investing in false assumptions, invest in a process that understands that having it all figured out in advance is the most dangerous assumption of all.
Jaeger Consulting Group provides Point of Sale System optimization support to connect business goals to software solutions.