Agile is fundamentally easy to describe. Why is it still so hard to do?
Agile has become a very successful and widely adopted methodology for managing projects, particularly in software development. But many people still struggle to adapt the approach to their context. I explain how agile can be applied effectively in one of these situations; developing a disruptive technology. I’ll use a recent ZOZO project as a specific example of adopting a pragmatic approach in applying the fundamental principles of Agile, to show how this works in practice.
Background
Agile practices aim to discover product requirements and develop solutions via the collaborative effort of self-organising and cross-functional teams and their customers or end-users. The Agile manifesto was created in 2001 by a team of very experienced programmers who addressed problems they saw were hindering their software development projects.
Twenty years later many software teams still struggle with how, or even if, they should be Agile. But few people would disagree with the values stated in the manifesto:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
The challenge is how to put these ideas into practice. An industry of books, training courses and certifications have been created to help implement Agile in different contexts. But this deluge of information can seem overwhelming to teams struggling to get started or obscure the fundamental principles. For example, the Association for the Advancement of Medical Instrumentation (AAMI) has created a well-intended and thorough technical report on how to apply Agile in a regulated environment, which is long on detail, but perhaps loses the spirit of Agile.
I believe the key for getting the most from Agile is to follow a pragmatic approach and not get too bogged down in the details. To illustrate this we will use an example of a product developed by the engineers at ZOZO New Zealand.
Creating software for a disruptive technology
A disruptive technology is a new innovation that significantly alters the way a market or industry functions. For most tech businesses, creating a disruptive product is the ultimate ambition, as it can allow companies to leapfrog the competition or even own a new market.
The first step along the path to creating any new product is usually to build a functional prototype. This usually requires substantial research and experimentation to solve the customer's problem. There are many unknowns at this stage of development and it is usually difficult to predict what problems will arise, how fast the team will make progress, which approaches will work, and when breakthroughs will occur.
When a research team runs into these challenges it can be tempting to assume that it is impossible to apply any structure to the development process. However, the Agile principles are actually perfect for addressing uncertainty, and can be applied just as well to research projects as they can to more mature products, though the approach is slightly different.
To illustrate this, let’s look at an example of how the R&D team at ZOZO New Zealand used an Agile approach to create a new and disruptive technology.
ZOZOSUIT: Accurate 3D body scanning made easy
In November 2017, Japan's largest e-commerce fashion website ZOZOTOWN announced that it was going to revolutionize the way that consumers buy and wear clothes: by providing their customers with a free stretchy body suit that would enable them to capture a precise set of body measurements using their smartphone, and then shop online for perfect fitting clothing.
The idea was an instant hit in Japan: within a few months over a million pre-orders were received for the ZOZOSUIT. The team in New Zealand were given the formidable task of rapidly developing the computer vision algorithms and software that would power this revolutionary new tech.
In new product development, the problem statement is usually known and comes from the market. For the ZOZOSUIT, the team needed a low-cost easy-to-use technology that could accurately establish a customer's size in order to fit clothes purchased online.
A small R&D team was assembled to tackle this problem. They created a series of rapid prototypes in MATLAB to explore different approaches and refine their ideas. Once the approach was proven by testing, it was ported to the target environment (C++ code running on a smartphone). The user interface was largely developed and tested, with the help of a specialized team, in the final few weeks before the product was launched.
The final product was a smartphone app (iOS and Android), a cardboard stand for holding the user's phone, and the stretchy ZOZOSUIT (available in 10 different sizes). To capture a 3D scan, users would don the suit, prop their phone up on the stand, and then capture a series of photos with the app as they slowly rotated their body around. All the image processing and 3D model construction was done on the phone and completed within a few seconds. Users would then be shown a 3D mesh model of their body, together with their full set of tailor measurements.
How does Agile relate to this project?
In the case of the ZOZOSUIT project, the back-end product was almost entirely developed functionally before any end users were directly involved. This might seem to be the opposite of how the customer-centric Agile process normally works. But if we take a pragmatic view and focus on the spirit of Agile then we can see the practices used in the ZOZOSUIT development align well with the values of the Agile manifesto.
To understand this better, let's take a closer look at what happened at the various stages of the ZOZOSUIT development process. There was a
research phase using rapid prototyping, followed by
software development, porting the code to the target platform, followed by
user trials, validating the ported code on the target platform.
At each stage an iterative design-implement-test cycle was followed and progression from one stage to the next was dependent on meeting certain criteria (working functional prototype, fully ported codebase, validated release). We can visualize the development process that the team used like this:
The diagram above does not appear in any Agile books or courses, and it might not feel familiar to experienced Agile practitioners. So far I have not mentioned scrums, sprints, Kanban boards or any of the other buzzwords normally associated with Agile. But these are not the things that define Agile.
Did the ZOZOSUIT development process described above adhere to the Agile values mentioned earlier? Let's go through them again and see...
Individuals and interactions over processes and tools
A small team created a series of prototypes to develop and validate the candidate solution.
Working software over comprehensive documentation
The functional prototype was tested against multiple test cases, along with interaction between the researchers and developers, enabled the software developers to create the target Smartphone app.
Responding to change over following a plan
Rapid prototyping is all about responding to change - in this case the emergent change in understanding the technical problem and the solution.
Customer collaboration over contract negotiation
Where was the customer during the ZOZOSUIT development? Well, in the early prototyping stages the researchers themselves acted as the 'customer' for the purpose of building a functional prototype. They knew the solution needed to work reliably and accurately in a wide range of environments. ZOZO Japan also provided continuous feedback throughout the development process based on their knowledge of the market and what was likely to be acceptable to Japanese consumers. And towards the final stages of development end-user feedback was gathered to design and refine the front-end app and user interface. So there were effectively multiple people acting as customers long before the code reached any end-users.
Role of Agile in creating minimal viable products
The aim of product development is usually to get to a minimal viable product (MVP) as quickly as possible. Being first-to-market with a new product or feature can create a strong competitive advantage. Early deployment also provides the most valuable possible feedback: whether people like the product or service enough to pay for it.
Thinking of product development in terms of the MVP helps to focus the team on developing and testing the things that matter the most. What are the must-have features for the software to be useful? What features could be omitted in the first release? And what does that mean for the development roadmap?
As we have seen for the ZOZOSUIT example, Agile processes can help the team to work through these questions and create an MVP. They can also help to improve, extend and maintain a product after it has first been launched. Agile supports and encourages incremental development.
A great way to learn about and understand a problem is to write software to incrementally solve it.
The MVP must be working software that is testable and tells you something new to help you make progress. The point of small releases to the customer is to get regular feedback and keep on track. The feedback for the core technology is provided by the prototype being validated under testing to meet defined functional and performance measures.
Update the product when you learn something: isn’t that just how science works?
Role of Agile in Software Quality
Perhaps the most important thing that the software engineering community has learned from Agile is how to establish and maintain quality in software.
One of the great advantages of using software (as opposed to building hardware) is that it is easy to change and extend functionality. But that flexibility can also produce unintended changes in functionality unless protections are put in place to protect the codebase. This protection is what we mean by quality in software.
To help us build the right thing the prototype code must be
easy to understand and
validated against the problem to be solved.
To help us build the thing right the production code must be
easy to understand and
verified against the prototype and
easy to maintain: e.g. follow SOLID principles, Test Driven Development, etc.
Quality at the prototype, research or learning stage is different to quality during development on the target platform, although there is some overlap: the validation tests created for the prototypes can often become part of the verification acceptance tests for continuous integration in the production code. In all cases, adopting Agile methodologies at every stage of development can help to establish and maintain software quality.
It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. - Richard Feynman
Take-Aways
Agile is first and foremost about small teams communicating well [1, p. 161]. Big problems are divided up across multiple small teams focusing on specific problems.
Think about how to apply the Agile values from the manifesto in your situation. When learning about Agile or trying to put it into practice don’t get bogged down in the minutiae of the processes you read about. You can, for example, use Slack instead of daily stand-ups if that works for you. Just don’t forget communication is less ambiguous in person.
The customer, as in the provider of feedback, is not necessarily the end user or the person paying for the software. It might be a regulatory body, a colleague, an independent expert,
or it might just be the real world - after all, that is where we and our software live.
Finally, add quality early and often. What that means will depend on what you are doing. If you are going to share or reuse prototype code then maybe it needs to be treated as production code.
The ZOZO New Zealand team are now building the next generation of ZOZOSUIT using Agile development methodologies and rapid prototyping. The new ZOZOSUIT will be available as a licensed software development kit (SDK) to international partners looking to build innovative products and services that leverage our latest 3D body measurement technology.
References
^ R. C. Martin, Clean Agile: Back to Basics. Pearson, 2019.
Gordon Macdonald
Gordon started his career in geophysics and gradually migrated to product development. Over the years he has managed multi-disciplinary project teams in a wide range of industries. He enjoys the challenge of leading software engineering teams and is a fan of modern practices including Agile and Test Driven Development. When he is not in the office Gordon enjoys tramping, cycling and appreciating life outdoors.
Comments