Article summary
Over the past several years, agile software teams have recognized the necessity of welcoming designers into their ranks. At the same time, organizations throughout the industry have struggled with and offered different perspectives on the “best way” for designers and developers to work together on agile teams.
Some agile purists argue for a “Sprint Zero” of a few days to a few weeks as a good chance for designers to get the lay of the land before they have a hungry agile development team nipping at their heels, waiting for work to build. Others criticize the idea of “Big Design Up Front” (even a quick “Sprint Zero”) as being a waterfall—and therefore bad—practice. In their view, design and development should both start at Sprint One, and start delivering value each sprint, right away.
At Atomic Object, we’ve staffed integrated design and development teams since 2009. Since then, over the course of many projects of different durations, budgets, and team sizes, we’ve evolved and refined our own agile process to maximize for project success.
Drawbacks of “Sprint Zero”
In the early days of our agile design-development journey, we typically took a “Sprint Zero” approach. Everyone on the team would start at the same time. The developers would spend the first week getting dev environments and software stacks spun up, while design raced to shell out the first few stories. We encountered several problems with this approach:
1. Rushed design, harried designers
On agile projects where designers and developers start at once, it feels like starting a treadmill at full blast without warming up first—you’re constantly at risk of falling off and making a fool of yourself (or getting seriously injured).
Developers are expensive resources. Letting them sit idle, or forcing them to work on low-value items from the backlog because design isn’t ready, is costly. Under the “pure agile” everybody-starts-at-once model, there’s a huge pressure on designers to “just get it done—just design the feature” without taking a step back to think about the implications of a decision. This pressure leads to uninspired, unpolished design. And while agile promises the chance to go back and fix it, I’ve rarely seen this happen. Given the choice, even with strong coaching, most software stakeholders will spend money on more features, versus reworking what’s already there. Besides, wouldn’t it be better to get it right the first time?
2. Poorly architected projects
“Emergent design,” “agile design,” and the like encourage software teams to approach projects on a feature-by-feature basis, without pausing to survey the entire architecture of a project. In my experience, approaching projects this way not only leads to the rushed, harried feeling I mentioned above; it also leads to software with poorly designed information architecture, redundant patterns, and inelegant workflows. Over time, an “agile design” will become like an old farmhouse that’s had too many wings added to it: The traffic flow will be all wrong, the closets will be in weird places, and it will just look kinda funky.
I’ve seen the same thing happen on the development side of the equation: The moment somebody says, “If only I had known this three months back, I would have decided to do x and saved us so much time.”
3. Unvalidated design
As software consultants, we have to validate our design with two different groups. It has to be approved by our clients, and it needs to be tested with their target users. Often, this leads to cycles of feedback and iteration within the design. In many cases with a pure agile approach, the software will be built before the design is ever validated with the stakeholders or put in front of users, leading to cycles of rework for the development team.
4. Unnecessary cost & rework
Bad architecture and unvalidated design leads to rework on the project, inflating cost. Without a bird’s-eye view of the product, designers lose the opportunity to develop an extensible library of design patterns that get applied consistently throughout a project. While it’s theoretically possible to leverage existing patterns in a pure agile environment, it’s much more difficult due to the rushed pace. Additionally, changes in existing widgets must be done carefully to ensure that functionality in existing implementations is preserved. In products that have been released, it can be disruptive to the user base when a feature suddenly changes.
Rework also happens when a new feature stretches a design paradigm beyond its limits. For example, new functionality could cause the existing navigation to become nonviable.
5. Unpredictable projects
In my opinion, probably the worst effect of “Sprint Zero” agile design is that it leads to surprises during development.
In a typical “Sprint Zero” project, the team would begin by shelling out a development backlog based on the project story map that we created in collaboration with our client. Developers would estimate the stories based on the information they had at the time (typically, a sentence or less of description about the feature). Large and nebulous feature sets (“reports” is one of my favorites) were typically given correspondingly large estimates.
Inevitably, as things were designed, some features grew beyond the scope of their estimates. Other features (after we and our clients thought about them more carefully) prompted new questions leading to new features.
At Atomic, we engage in a fixed-budget, scope-controlled way. Understanding that there are almost always more ideas than time and money, we work with our clients to define and build the best possible software for their budget, prioritizing the features that deliver the most value and pivoting based on learnings along the way. “Sprint Zero” engagements led to missed opportunities and disappointments in this area–clients found it difficult to make the tradeoffs necessary for this approach to work.
Our Alternative to ‘Sprint Zero’
As our agile process has evolved over the past few years, we’ve pivoted to a model of doing “Some Design Up Front.” For most of our projects, we typically start with a Research, Design, and Planning phase which allows our team to deeply understand our client’s vision and needs before we get started building. In my next post, I’ll discuss in more detail how we staff this phase of the project and how it helps us avoid the pitfalls I mentioned above.
Thank you for the insightful post. I recently joined a major software development project mid-way through its lifespan (as a designer) and I’m experiencing the effects of 1-4. I would like to add that #1 especially is very detrimental to morale which may cause consultants to transfer off your project (if it relies on consultants). This may be very dangerous to a long-term project if the practices for documentation are lacking – resulting in poor or even non-existent documentation. As the knowledge is not documented and instead bound within individuals (or even the code itself) and not freely available, that knowledge is essentially lost if a key individual should transfer off the project.