How We Build Enterprise-Size Software: Part 1 — Small Increments
Our best successes have come from staying small and constraining resources.
--
We wanted to share a little about what makes our software development possible in this multi-part series. See below for case studies from clients such as Auckland Transport and Skinny, and take a look at ‘Part 2: Constraints’ here.
Achieving Better Outcomes With Less
We define big software builds as applications needed for thousands of staff, users, or stakeholders, usually with complex integrations with other systems.
The requirements can be met in a large number of combinations, and stakeholders need this software to improve and evolve over time.
Building large software systems for complex sets of requirements is something we’ve had a lot of experience with, and our best successes have come from staying small and constraining resources. We’ve also had direct experience with many large, well-funded initiatives that, in the end, failed to deliver on their promise.
We advocate a simpler-is-better approach, urging our clients to use less money, fewer people and shorter time frames in pursuit of less complex goals. To enable this, our large-scale engagements typically follow a lifecycle that has its roots in Agile, Lean, Lean Startup and Design Thinking.
We start small and work to validate hypotheses before committing significant resources to a major initiative. Once experiments have validated key concepts, including the underlying business model, we scale our effort to build applications and eventually, platforms.
Our thinking is neatly summarised in F.I.R.E.
Fast
A constraint on time to reduce the risk of change that comes with long schedules.
Inexpensive
A constraint on budget to encourage a mindset of thrift and re-use.
Restrained
Restraint in all things — small budgets, short schedules, small documents, small teams, and small components.
Elegant
A constraint on complexity to encourage simplicity, in all it’s pleasing elegance.
How We Do It
The following methodologies heavily influence our software development:
Agile
Agile software development helps all stakeholders focus solely on activities that generate business value. All activities are connected back to a business outcome and prioritised for the value they are expected to deliver.
Agile embraces the notion of perpetual beta — customer needs going in and ‘good enough’ software coming out. This mindset encourages us to validate software early and often, with real users. Put another way; there is little benefit to building excellent software that no one uses.
We practise Agile in small, cross-functional teams that have a high degree of autonomy. In line with F.I.R.E. principles, these teams typically have all they need to move quickly, with few impediments, measurable outcomes, and useful data.
Lean
We incorporate elements of Lean thinking for its emphasis on efficiency and achieving “Flow”. We seek to address the root causes of waste and rework and balance steps for maximum velocity.
Lean Startup
Two aspects behind Lean Startup are particularly appealing:
- All ideas are hypotheses until proven
- Proving an idea extends to validating the business model behind the idea, not merely the software
We use the notion of experiments to validate ideas rather than making big bets. Once an experiment has proven we are solving a real problem (problem/solution fit), we move to validate there is a viable market for the solution (product/market fit), before over-investing and trying to scale.
Design Thinking + Design Sprints
We often incorporate Design Thinking, as popularised by IDEO, to inject a more customer-centric viewpoint into the digital process. It typically involves “jumping” forwards and backwards between what’s possible, what’s wanted, and what makes money.
The combination of direct observation, empathy research, crude prototyping, and other techniques help us synthesise insights before writing a line of code.
We also often draw upon Google Ventures Design Sprint methodology to help compress strategy and ideation into short “sprints”. The five-day process draws on Design Thinking principles to include design, prototyping, and testing ideas with customers.
Case Study: AT Customer Central
Auckland Transport have set up an initiative named Customer Central that focuses on the development of applications and features led by consumer need. We employ design sprints to build a roadmap of features. These are then fed into a backlog of user stories with associated visual designs. Developers then conduct a series of sprints, working towards a product release.
We have completed several releases of a mobile journey planning and notification app (pictured above), have converted a paper-based Personal Water Craft registration process to an online process, and are working on a sophisticated public transport disruption system. All of these products have a continuous backlog of work to add features in small iterations based on prioritised customer feedback.
Product-centric (vs Project-centric)
We structure each software initiative as a step towards building a grander product or platform vision. This approach allows both developers and stakeholders to keep initiatives small while not losing sight of the bigger picture. Gone are the days of all-encompassing software development projects with a “do it once, do it right” mindset, where a system would be built and left to languish until a large budget was sought to replace it.
Instead, like modern software products, we typically build in small increments, releasing changes frequently — keeping the software fresh and relevant
Case Study: Skinny Mobile
When Skinny Mobile launched its new direct-to-customer offering, Skinny Direct, they chose us to develop their consumer web application, customer service portal and mobile app, including deep integration into their own and third-party provisioning systems.
We worked with Skinny’s marketing and product teams and 3rd party graphic designers to conceive the user experience. At the same time, our technical designers worked with Spark Wholesale and third party engineers to design the integration.
We ran the project in agile sprints, releasing to a cloud based production environment that was sheltered from the public so as not to reveal the new product before Skinny were ready to launch. We carefully coordinated activity to make the products live in line with media announcements.
We continue to add features to this product and support the applications and their infrastructure on a 24 x 7 x 365 basis.
Stay tuned for part two, where we discuss what a typical project journey looks like.
Want to chat with us about anything in this article? You can reach out here.
