Are successful outcomes always achieved by earnestly following the same strict agile methodologies for every software project, regardless of the client, the industry, the project type and project size? At Sandfield, we believe the answer is no.
Over the past 30 years, we’ve witnessed the introduction and evolution of many different agile methodologies in the software development industry but we have remained steadfast in our somewhat unpopular approach of avoiding any specific methodology e.g. Scrum, Extreme Programming (XP) etc.
Instead, we’ve remained agnostic and cherry-picked from the tools and approaches available to best suit each individual customer’s needs and project deliverables with our overarching guidance provided by the Agile Manifesto. This allows us to remain focussed on outcomes rather than following rigidly defined processes.
To provide context for the approach, tools and practises discussed in this article, I’ll first summarise a project for a Sandfield customer where our strategy was applied.
Mainstreet project
Mainfreight is a customer I’ve been working closely with for the past 12 years. They are a global company with annual revenues of $2.95 billion, of which $1.33 billion of operating revenues is currently flowing through one of the systems we’ve built for them called Mainstreet.
Mainstreet is a custom domestic freighting application that took 211,356 man-hours (110 work years) to build and go live in New Zealand, Australia and the US. In NZ alone, Mainstreet is managing 70k - 100k of consignments per week. It has a production database that’s churning through 20k transactions per second and is now sitting at 2.4Tb of pure data (excluding documents) after just two years in operation.
This mammoth, bespoke, enterprise-level ecosystem was successfully developed and implemented into three very different country-specific businesses without subscribing to any single ‘best practice’ methodology. So how did we achieve such a feat?
The following is what I believe are four key ingredients of our ‘secret sauce’. I also believe that this Sandfield approach trumps strict adherence to a rigid methodology every time. We’ve delivered positive outcomes consistently for Mainfreight and the rest of our customers at Sandfield by adhering to these.
Proven frameworks and platforms to build on
In addition to our base technology stack, we’ve built up an extensive list of in-house frameworks and platforms such as Origin, our supply chain platform and On Account, our financial management system platform, that provides us with a head start on any new custom build.
Millions of dollars have been invested in these tools to make them robust, easily scalable, performant and resilient, with an extensive list of “out of the box” functionality that has been built up over many years. The benefit to our customers is that it minimises the risk of building a system on flawed base architectures. These tried and tested frameworks and platforms are used as building blocks so we always kick off our projects with an immediate head start. This frees us up to develop value-add customisations specific to our customers’ needs, rather than spending valuable development hours reinventing the wheel.
Mainstreet was built on both aforementioned supply chain and accounting platforms as well as numerous other frameworks to implement the vast array of modules that exist within the system e.g. addressing, users, contacts, calendars, time zones, security, document storage, mobile devices and applications, EDI, and many, many more.
Flexible development windows
Pre-defined ‘sprints’ have often been touted as an essential tool to ensure that engineers have the pressure of a short sprint in order to maintain momentum. We reject this as our team are determined professionals that are accustomed to delivering systems on time and on budget.
Instead of sprints, our approach is to plan in development windows according to each project. Factors determining the design of a release include the staging of the project, the key deliverables needed per stage, code stability considerations, breadth and complexity and the risks associated with how much functionality is produced given team size and resulting testing effort.
For part of the Mainstreet implementation, we had large modules to traverse in the pre ‘go live’ stages and development windows were chosen accordingly. These ranged from 9 to 14-week development cycles for 8 full-time developers with 4 - 5 week UAT cycles. At 75% utilisation per developer, this worked out to be approximately 420 days of development for a 14-week cycle, so significant system changes per window.
The reasoning for such a large functional deployment allowed us to complete builds for extensive modules without the need of patching code together purely to hit a deployment date, which can occur in ‘sprint’-driven environments. Think of it this way, would a surgeon performing open-heart surgery prefer to complete the job in one operation, or stitch the patient up halfway through the procedure to come back later and proceed?
Post-go-live development windows are now floating between 5 to 8-week development cycles managed by a resourced-up team. These medium length development cycles provide a quick turnaround of functionality to support the business, de-risk go-lives by avoiding massive change and also avoids inefficiencies around regression testing smaller releases.
In-flight reviews
In the Mainstreet pre-go-live example provided, 420 days of development was quite a hefty amount of new functionality to be delivered all at once. To address this, we conducted in-flight reviews. By doing so, we avoided the disruption and inefficiencies of temporarily standing up large builds mid-development window. It also ensured that what was finally delivered would suit the business processes and users.
In-flight reviews like these allow our clients to review partially completed modules in our development environments as they reach critical milestones well before completion. This provides opportunities to review the details of screen designs and to talk through business rules with something tangible. This is essential for catching any shortcomings or misunderstandings in functionality early in the process and allows us to pivot as required.
Streamlining the SDLC
One of our strengths at Sandfield and a niche capability in the software industry is that all our developers are involved in the entire SDLC (Software Development Life Cycle), with all developers talking directly to customers at all phases of the life cycle. This is atypical of the industry, but for us, we’ve found that this greatly increases efficiencies around project delivery.
Our industry views this as a risky approach, but we proactively mitigate this risk. For the past 16 years, we’ve invested in soft skills training for the entire Sandfield team from our external consultant, Roseann. Roseann trains us 4 - 5 times a year every year to support and enhance our internal and external communication.
I have personally been coached by Roseann for the past 12 years and it has improved how I (and many others at Sandfield) communicate, manage relationships, and deliver on projects not to mention the positive impact it’s had on me personally. Thanks, Roseann, we really appreciate you!
Conclusion
In short, at Sandfield we avoid the ubiquitous ‘cult of agile’. Instead, we choose approaches that are specific to each business problem. There are other considerations, approaches and factors that aren’t detailed in this blog, but the key theme that guides us is that everything is customer-centric and always focused on outcomes while adhering to the concepts detailed in the Agile Manifesto.
Rigidly following predefined rote processes may be inefficient, expensive or counterproductive for the outcome you seek. If I can leave you with one key takeaway from this blog, it’s this... ask yourself if the software project you’re involved in is truly outcome-focussed. If the answer is no, perhaps it’s time to consider an alternative approach and develop your own secret sauce.
