‘Forget about design! We’re a software development company; we are Agile!’ Really? This is a common misconception: that the Agile method replaces design. It doesn’t. (Note: the Agile method(s) being promoted today isn’t the same as the original Agile manifesto published in 2001, Utah). You can find it at agilemanifesto.org, and for your convenience, I’ve shared it below. Let’s consider it together:
‘Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.’
(The above statement is clear. It’s not suggesting companies should discard documentation, as often misinterpreted by Agile software development companies that neglect proper documentation. Instead, it advocates creating valuable documentation that supports the team’s progress. As stated, ‘The Agile movement is not anti-methodology; in fact, many of us want to restore credibility to the word methodology. We embrace modeling and documentation, but not to the extent of filing endless diagrams in dusty corporate repositories. We plan but recognise the limits of planning in a turbulent environment.’ Agile Manifesto History.)
‘Principles behind the Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.'
(This is key. Companies misunderstand Agile and assume designers should only be involved halfway through the process, skipping a structured design approach. They think only partial or ‘just enough’ design is needed. But the manifesto clearly states that proper design enhances agility. Technical excellence and thoughtful design go hand in hand.) Continuing:
‘Simplicity—the art of maximising the amount of work not done—is essential.
The best architectures, requirements, and designs emerge from self-organising teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.’
The Agile manifesto and its principles are valuable for most digital companies. However, it’s unfortunate that many organisations invest heavily in Agile methods like Kanban, Scrum, and XP without fully understanding the true essence of the manifesto or checking if these methods actually fit their needs. A methodology shouldn’t be a rigid set of rules (I wrote about design methods on my essay What is Design: Beyond Aesthetics and Function), but many Agile frameworks impose that kind of rigidity. The Agile manifesto doesn’t prescribe rigid structures or rules, like daily meetings (in my experience, I’ve never seen anyone in a team who was happy with these) or two-week sprints. Instead, it focuses on principles and values that should guide how practices are adapted to fit the organisation’s context.
Here’s a personal anecdote: I can eat ice cream every day and not see a difference in my weight, while some of my friends seem to gain weight just from watching me enjoy it! What does ice cream have to do with Agile? Each of us is unique, and what works well for one may not work for another. Similarly, companies are unique organisms with their own ‘biology.’ Scrum might not work for you as it does for another company. We need to determine our own workflow methodology based on team size, business goals, and what we aim to achieve. Do we want to deliver features quickly, as a startup might, and redo it in subsequent sprints? Or are we focused on developing high-quality products, like a mature company, even if it takes a few more weeks? There’s no one-size-fits-all solution.
I often see companies, particularly software development companies, struggling to articulate a long-term vision for their products or business. I once spoke with a Scrum Master at a company with over 20 years in the market. I asked why they didn’t have a proper design process, given that they seemed to implement features over one or two sprints only to redo them in the next. His response was, ‘We can’t plan ahead because things, you know, are uncertain—technology and the market change all the time. We don't know what we want for our product next year, so we release and wait for user feedback. That’s why we use Agile; we can’t afford to spend time designing products when we don’t know what’s going to happen next year.’ (OMG, I thought).
Is it really acceptable to spend time and money redoing products every two months, all while crossing fingers for user approval? It might make sense to use Agile for short-term actions, like bug fixes, but a business with no long-term vision is essentially without strategy. Poor decisions follow, resulting in indecision among managers, delays in product development, and unclear communication within teams.
‘Alice asked the Cheshire Cat, who was sitting in a tree, “What road do I take?”
The cat asked, “Where do you want to go?”
“I don’t know,” Alice answered.
“Then,” said the cat, “it really doesn’t matter, does it?”
― Lewis Carroll, Alice’s Adventures In Wonderland
If you don’t know where your business is headed, does it really matter if you use Agile or any other method?
Jeff Bezos and Design
In contrast to the traditional approach, the Working Backwards method focuses on planning and development by starting with the end goal in mind and then outlining the steps required to reach it. This approach emerged in 2004 when Amazon’s e-commerce strategies were thriving, and the company was actively pursuing new opportunities with large market potential. Instead of diving straight into product development—something often encouraged by an agile mindset (e.g., ‘let's just ship these features and see what happens’)—Amazon promoted a slower approach to enable faster progress later. CEO Jeff Bezos, who referred to himself as the ‘chief slowdown officer,’ would step in to prevent teams from rushing into coding before clearly defining the customer problem or designing a thoughtful solution (Harvard Business Review, Colin Bryar, Bill Carr). The Working Backwards method aligns with a strategic, intentional approach in design, where reversing the process ensures clarity and purpose throughout.
Agile is undoubtedly useful when developing something new and moving quickly is important. But, if you’re unsure about your users’ needs or the customer problem, Agile becomes trial and error. Agile, combined with design, is more effective for creating meaningful, data-driven, and error-minimising products—rather than crossing your fingers and hoping the customer likes what you’ve built.
As James Clear said in Atomic Habits: ‘Goals are good for setting a direction but systems are best for making progress.’ Agile can certainly help build products efficiently, but what’s the point of efficiently building the wrong product? IBM, for instance, brought design (in the form of Design Thinking) into its business, yielding significant results. According to Doug Powell, IBM Distinguished Designer, ‘Teams applying IBM’s Design Thinking practice, adequately staffed with design talent, are getting to market twice as fast and seeing up to a 75% reduction in design and development time.’ Isn’t that a good reason to practise design at your company?
However, remember, hiring product designers solely for their ability to create high-fidelity, glossy mockups or visually impressive portfolios may not yield the results your company needs. While these skills are valuable, they are more closely aligned with the role of graphic designers. Before hiring, take the time to understand your company’s specific needs and the unique contributions a product designer can offer, such as problem-solving, user experience enhancement, and product strategy. Great designers see the bigger picture. They understand the entire ecosystem surrounding a product and the business, working alongside other teams to guide the product through its lifecycle, from initial concept to launch and iteration. They help set clear goals and work towards achieving them, ensuring that the product not only meets user needs but aligns with broader business objectives. They consider everything—from socio-political and economic factors to sustainability, ecology, and psychology. By connecting these dots with a thoughtful, systematic approach, they create effective, meaningful solutions. So, if you want to build something exceptional, make sure design is part of your strategy from the start.