Development Methodologies for the Development of Supply Chain Systems

Introduction

A development methodology, in software terms, is essentially an infrastructure of software engineering practices and processes used in the development of an application. I have been exposed to and involved in a number of IT system development methodologies over the years. I have been involved in teams that have created their own flavor of ad hoc development methodologies, XP, Waterfall, Scrum and even involved on a integrations project with a client who claimed to be implementing ‘Project Driven Development’. In almost all cases the projects have been late, expensive and not really met the users needs and standards to the degree that we would have liked.

Methodology Quick Run Down
Waterfall

The waterfall model is the classic bad boy where each step in the development process is locked in an unchangeable flow of events. For example you completely finish the requirement phase of the project before starting with the development phase. This works well in the construction industry because the people doing the design and architecture are the specialists and the constructors who actually build the building aren’t actual engineering specialists. However in development of applications we find that both the architects for the systems and the developers themselves are specialists facing specialist problems and thus this frame of thinking doesn’t accurately fit software development more than often resulting in expensive and over run project deadlines.

XP

Iterative agile set of engineering practices based around smaller iterations of development. XP is not only a development methodology but it also includes a number of engineering practices such as test driven development and pair programming. XP is most easily defined through its well thought out set of values and principles which dictate how members of the development team interact with themselves and business while developing the application. I've worked in XP teams and maybe we didn’t implement it correctly but the methodology didn’t seem to give the visibility, feed back and continuous learning as a project team that was needed to develop applications within the supply chain industry.

Ad Hoc Development Methodologies

Many companies follow their own home grown forms of development. In my experience these are mostly motivated by powerful personalities within companies not willing to give over control. Deadlines may have been reached but quality and long term objectives were sacrificed giving way to endless support issues.

RUP

More of a set of abstract process blocks that can be applied to development methodologies defining goals that need to be achieved along the process. To be honest I haven’t had experience with RUP but it’s a famous methodology so I thought I’d list it.

Scrum
Scrum is an iterative development methodology focused on project visibility, quality and agility.

Properties of Supply Chain Software

In my post on the properties of supply chain applications I presented a retrospective view of the development of supply chain systems in which I speculate that supply chain projects suffer due to a highly adaptive and changing industry. Often the systems and the development of those systems can’t keep up with the pace of the changes that the industry requires. For example in the retail sector the goal has always been to land the good with the lowest possible cost closest to the agreed upon date of arrival as possible - there will never be a drive for system loyalty as you find in heavily regulated industries such as the banking industry because the extreme pressures on landing goods at the lowest possible cost drives creative, aggressive and adaptive solutions within the business work flow itself. IT seems always to be lagging behind, battling to catch up to the real needs of the business.

I have Found Scrum to Work the Best

I have recently been involved in a very successful and on time implementation of a Forex management application in the retail sector of supply chain management using Scrum. A great introduction to the methodology can be found in a paper entitled “The New Methodology” by Martin Fowler in which he describes the nature of the methodology, namely in that the methodology provides project visibility as well as stable, high quality software while at the same time providing for a late change in requirements which results in a competitive advantage in the form of frequent releases of functional software which enables business to make immediate use of needed features as well as giving business the visibility into the progress of that project on high and detailed levels.

Scrum Allows for Rapid Change and That's Why it Works

All features that need to be developed in Scrum are analysed and placed on a list of tasks called a backlog. The backlogged items are ordered by functional priority by the needs of the business so the most important features are developed first for every development cycle.

The methodology then breaks development into decided upon time frames called sprints (a time frame of 2 weeks is suggested). Typically a deployment will follow the successful completion of each sprint. Each feature is point rated upon an accurate complexity rating and the development teams velocity is calculated based on the number of points a team finishes per sprint on average. Therefore, if left alone, the team can very accurately produce and deploy the consistent amount of work they committed to at the start of the 2 week sprint.

The features that the team works on during a sprint is locked down and un-changeable for the sprint. The order of the remaining features on the backlog can be changed dynamically by the business. I believe Scrum works for supply chain development because it enables the company to change that order if needed, making a feature that wasn’t important before the most important thing and because it becomes the most important feature it will then be developed firstly in the next sprint. The stable and consistent releases mean that the business will receive the most urgently needed functionality every 2 weeks therefore enabling IT to respond to the needs of the business dynamically.

Visibility is then provided back to the business in the form of a burn down charts and kanban boards detailing how and when features are completed. Because each feature is developed as a functional unit it means that when a feature is "done" it is usable by the business right away.

Summary
Development teams need a certain level of consistency from business in order to create IT solutions that are stable and secure. In supply chain the businesses needs fluctuate violently while business try to provide a competitive advantage through supply chain. Business need IT to be able to respond to their needs as the need arises. Scrum provides the balance between the needs of the IT development team and the business which results in a high quality IT and business solution.


Do you agree? I would love to hear your thoughts on development methodologies and supply chain IT!