Scrum in Logistics: a business case

The logistics industry is quite large and contributes to a sizable amount of the world GDP as well as being an essential component for goods exchange within and between countries. However, it is quite disparate, consisting of a multiplicity of actors of considerably different sizes and different levels of professionalism. The 10 largest freight forwarding organizations controls only 45% of the market and have embraced Agile ways of working only on an ad-hoc or partial basis. Logistics processes are for a great part still very much manual and although good progresses have been made, automation and integration are still lagging behind. This has lead in some parts to the emergence of e-Logistics startups which intends to change this industry by “digitalizing” the supply chain. Who between the traditional logistics and e-logistics actors will remain in some years has yet to be seen but Agility and notably Scrum will definitely play a role.

The case presented here demonstrates that it is not only possible to use Scrum in Logistics but also that it can be done with a high level of efficiency and great results. This case also demonstrates that Scrum can not only be applied to product development but to projects as well.

The context is seen from a Logistics Service Provider (LSP) which offers comprehensive logistics services to its clients such as local and international transportation, warehousing activities, consolidation activities, quality control and customs brokerage.

The Business

The customer is a premium Italian fashion company specialized in several lines for women including clothes, blue denim collection, shoes, accessories, luxury collection, beachwear, underwear, leisurewear sport collection and kids wear.

The concerned business was a warehousing distribution project for the whole Italy and Europe with inbound flows coming from China and Turkey (production countries). The LSP was already responsible for the quality control, consolidation and international transport of goods via from China and Turkey to Italy. With this new awarded business, the LSP was extending the management of the supply chain to the distribution of goods to the European retail shops as well as B2C customers.

To support this new operation, the LSP required a Warehouse Management System (WMS) to handle the flows of goods within and outside the warehouse as well as multiple interfacing capabilities with its customers i.e. Electronic Data Interchanges (EDI). The project timelines were fixed (8 months) and non-negotiable. Pushing the deadlines even by a week would have meant missing a fashion’s season which was not an option for either party.

Traditionally, the LSP would come forward with proposals on how to handle the various flows – taking into account customer requirements – but here, the customer wanted to have a say on how the flows would be organized within the warehouse in addition to having specific and numerous EDI messages to handle at various point of time.

The Product

The product that the LSP used to support this project was based on the versatile WMS: JDA Warehouse Management (JDA WM), formerly known as Red Prairie Discrete. This application comes with endless possibilities of configuration, customization and development such as the design of your own screens (Desktop GUI, web based, Radio Frequency (RF) screens, etc…), processes, triggers, EDI messages and workflows. The possibilities offered by JDA WM ensure that one can build its own tools within this application e.g. billing module creation.

All development done by the team used the proprietary JDA MOCA language with the exception of Java for RF screen customizations. Code was checked in, unit tested and integrated with the existing increments in the form of packages which were deployed automatically via scripts into a 4 tier environment: Development, Test, QA and Production.

The technical tools for the development pipeline were Apache Subversion (SVN), Tortoise and JIRA software among others.

The Team

At the start, the development team comprised of 4 fully allocated members without any previous Scrum or Agile experience. The regional WMS manager in charge of the team had previously implemented Scrum in other teams with good results. The team had later to be extended by 2 more developers for reasons which will be explained later. The team was of international composure with Dutch, Indian, German and Italian nationals residing in various European cities.

Challenges

The challenges of this project were many – among the most important ones were:

Financial penalty for non- working system

In order to ensure that maximum attention and dedication was exerted by the LSP on this project, a one million euros clause penalty was inserted in the contract and was to be paid in case the system delivered was a non-conforming system as “per specifications”. Those requirements were to be inserted as an addendum to the contract (see next point)

Unclear and evolving requirements

The requirements expressed during the course of the project were all written in Italian, recorded in a contract addendum as time passed by and were subject to several changes except for well-defined interfaces. The requirements had to be translated in some parts into English to make intentions and details understood by the team. Naturally, not everything was or could be expressed in written form and some written statements were ambiguous which were putting the LSP in a dangerous financial situation.

Language constraint

The customer engagement was extremely difficult due to a simple yet major constraint: language. The customer was speaking Italian with very little knowledge of English nor willingness to use it. The development team itself had only one person speaking Italian with a limited understanding.

Interfaces and external dependencies

The number of electronic interfaces for this project was more than double the average WMS solution’s size (15 instead of 6). To make the matter more difficult, those interfaces were to be developed by a member sitting outside of the development team, creating a critical dependency.

Business Acceptance

The regional executive team who was overseeing this project had never heard nor seen any teams practicing Agile nor Scrum. Statements like “we have to be more agile in our way of dealing with customers” were common but without any practical understanding behind it.

Traditional way of working

The team was mature for some parts in the usage of JDA WM but was very used to the old way of working that is with one project manager developing a schedule plan, overseeing the tasks, reporting statuses to management and being the interface between the team and managers/customers. The mindset had to change with the development team taking ownership for their actions.

No co-location

At the start of the project, the team members were located in four different countries (Switzerland, Netherlands, Germany and Italy). This was not an ideal situation as it made communication more difficult and less effective.

Team composition and allocation

The team composition changed during the project as individuals had to be reallocated to support logistics colleagues on new business opportunities or assist to resolve complex incidents for operational people. Besides two to three core members, the focus factor of individuals on this project varied greatly.

Hard deadlines

There were two hard deadlines:

The start of the business had to be 1st of October as this was when the new fashion’s season was starting. Missing this date was not an option
Having all EDI interfaces ready by early July. Passed this date, the customers’ team members were on long holidays (July/August being holiday season in Italy) and not available to test nor answer technical questions

No physical warehouse

The contract was signed with the idea of having a dedicated warehouse and operational team ready for this new operation just one month before the starting date. This decision was putting a lot of things at risk i.e. how do you ensure that you have a working software supporting operations if neither those operations nor physical warehouse are available?

Finally, this was the biggest ever European logistics project for this LSP. Given that a US project with very similar components had taken 4 times the budgeted amount, overpassed deadlines and required a small army of external consultants to complete 2 years before, a new way of working was required…

And it had to be Scrum! But…why?

Why Scrum?

Many of this project’s challenges were actually what made it so fit to enter in the iterative, incremental and continuous improvement process that is Scrum.

For one, the requirements were unclear and fuzzy, left to several interpretations and written in a foreign language. Not everything could be clearly expressed but it had to work and properly support operations and the customer (think “working system”). We had to build something quickly to see if it worked and fitted the needs and requirements of the customer.

There was also no certainty that the originally assembled team would be able to absorb the required work but those hard deadlines had to be met no matter what (think “how much to do” vs “productivity of the team”). With Scrum and story points, we could track the productivity of the team and by reviewing and estimating the backlog regularly; see if we were on track.

Last but not least, the team was looking to develop the complete this project without heroics which characterize many of the projects in the Logistics industry (think “sustainable pace” and “product quality”). We wanted to claim back our lives.

Success factors

Besides the development team members themselves, those are key factors which greatly supported the team moving to Scrum:

A supportive manager. The manager who suggested and supported the introduction of Scrum within the team had implemented it successfully within the Corporate WMS team. This resulted in a high performant team developing innovative solutions such as customizable WMS templates reducing customer average implementation times by 2 months.

Corporate team and toolchain with Agile in mind. The Corporate WMS team who was supporting the regional WMS implementation teams was used to Scrum and was developing and sustaining a toolchain which supported Agile development (DevOps toolchain).

A dedicated Product Owner. This was the hardest sell and the biggest win that there was for the development team: convincing the regional Logistics executives that the team would not be able to make any progress without a dedicated product owner from Logistics. This was achieved by a tough negotiation tactic from its manager to the executives: without a dedicated PO, the development team would not be able to commit on the deadlines nor quality of deliverables for this project.

Progress and Successes

In this section, we provide the different steps that the LSP took to overcome the various challenges of this project.

Creating awareness

To start with, everyone in the team had to be trained on the Scrum fundamental elements (events, roles and artifacts) – this was done at the very start of a project. Due to budget and time constraints, only half a day was dedicated to training but we ensured that continuing education was not forgotten in this project (see value of certification below)

Creating visibility, inspect and adapt

Once the team has been trained and the product backlog created, it was important to exhibit visibility regarding our progress to our stakeholders. This was done via Sprint reviews where the logistics stakeholders could review the increment and provide feedback which would be later added to the backlog. Virtual Kanban boards were also in place through JIRA.

Taking ownership

By conducting the daily Scrum, we ensured that progress of items was made visible but also that the development team would take ownership of the items and start acting as a team.

Working as a Scrum team

The team had now to work as one with the completion of the Sprint goals in mind instead of being driven by the completion of individual tasks. The mindset changed from my tasks vs your tasks to our tasks – how do we progress as a team towards the Sprint goals? It took a couple of Sprints to sink in but once it settled, we had members giving a helping hand to each other without second thought. A good example was the testing period when where the most experienced member went sick, the other members seamlessly replaced him with a high level of motivation.

From I shaped skills to T shaped skills

JDA WM is a comprehensive software requiring several specialists to make full use of it. In a typical JDA project, roles segmentation such as project manager, functional consultants, techno functional consultants and developers are common. As soon as individuals in the team starting to work as one instead of being segmented to their role, knowledge sharing started to place. Individuals such as our business analyst would get involved in the area of configuration and testing, warehouse functional consultants started to get involved in the development of EDI messages, etc…

A strong Product Owner

This project had the chance to have a knowledgeable product owner who spent a considerable amount of time with the customer and the developers to elicit requirements and validate the backlog items completion. An Italian native, the product owner was a key interface between the customer and the development team. The team was in no way prevented from reaching out to the customer but language was indeed a barrier.

Sizing the backlog to commit

3 months after the start of the project and due to contract signature, the request came to commit to the deadline: was the team going to make it or not? By that time, the requirements had formed and had been expressed as product backlog items. A backlog refinement session took place to size the non-estimated PBIs. There was over 840 points to complete but the historical velocity was showing clearly that only a 440 points goal was achievable. Based on this review, a request was placed for an additional resource in addition to a few product backlog items change proposals. All proposals were accepted.

Value of certification

In order to foster continuous improvement and ensure that Scrum rules were lived and exhibited, a motivated member of the team was properly trained, certified and acted as a Scrum Master for the team. He ensured that the ceremonies took place with efficiency e.g. time boxed, ensuring that actions are taken after retrospectives, etc..

Co-location

The best registered progresses during this project were when the product owner and development team were meeting in person and on site. This was in Eindhoven (Netherlands) at first where most of the developers were located and Milan (Italy) later on. Several of those on site meetings had to be organized to ensure good progress in the development. When this was not possible, phone calls, video conferences and text messaging were used on a regular basis.

Include external elements within the Scrum team

While working as a Scrum team is an extremely efficient manner to deliver value, being dependent on externals teams which are not Agile is not. The strongest dependency was on an EDI developer which was not part of the team. After intense discussions between the regional WMS manager and the EDI resource manager, the EDI developer was included in the development team which helped tremendously.

Catering for variations

Scrum is optimum when the team composition does not change and that team members are fully allocated to the product development. In this case and for reasons explained under challenges, the % of allocation of the team members was changing during the project and even new members were assigned during the course of the project. The estimated % of allocation of each team member (focus factor) was estimated at the beginning of every Sprint in order to properly calculate the capacity for that given Sprint. This took into account holidays.

Example: the team has a historical velocity of 50 points per 1 week Sprint. Next Sprint contains a public holiday, the focus factor of each team is only 80% and the capacity for the Sprint would be 40 points (50*0.8) only

In order to have a proper baseline due to the focus factor, we referred to an extrapolated capacity of 5 Full Time Employees (FTE) working at 100% allocation in addition to the actual number of points done by the team.

Dry runs in the office

No warehouse space nor operations were actually available to test if the system would actually work under actual conditions till one month before go live. In order to remedy to this issue, some office space was used as fictional warehouse space and mock cartons, labels and merchandises were used to simulate actual conditions with the Product Owner acting as a warehouse operator.

Breakdown of features and stories

As the system required to support the operations was huge and complex, the necessary items were broken down into several components, among them where:

Configured system
Interfaces
DDAs (new screens)
Reports
Labels
User Devices
Triggers

Under each of those components would the related epics and stories be found. The components were be placed on a graphic board which would enable quickly to identify which components and epics were completed and therefore show the related progress of the team.

Continuous improvement

Throughout the project, the team never missed to go through retrospectives thanks to its Scrum Master. This ensured notably that elements of bad Scrum were discussed and acted upon. The elements ranged from very simple (e.g. individuals not coming on time) to more complex (e.g. improving the deployment steps)

Conclusion

Scrum can make the seemingly impossible possible and – thanks to empiricism – creates a reasonable amount of certainty and predictability in the uncertain and complex world of software development. Without doubt, this Logistics project would have utterly failed should the traditional project software development phases had been strictly adhered to. The timelines for a project of this size were quite strict without any place for rework or changes in a waterfall process. Scrum ensured that we had a working, tested and validated software at the end of every Sprint and that we could continuously reflect on our progress and possible improvements.

Naturally, not all the aspects of this project were approached perfectly – Scrum is after all, simple to understand but difficult to master – but Scrum is actually what made this project a success. After this project, the regional WMS manager went on to a different department and assisted development teams in scaling Scrum. At this moment, over 50% of the development teams in the LSP organization have adopted Scrum and/or another Agile methodologies (Kanban, XP…) thanks to earlier successes in the organization.

Key Acronyms