Strong Opinions, Loosely Held
While the debate over software development methodologies continues to rage, we prefer to focus on "the why" rather than "the how".
Technology entrepreneur and author Jason Fried recounts a meeting with Jeff Bezos, when the revered Amazon boss provided some wisdom on the subject of opinions. "He said people who were right a lot of the time were people who often changed their minds. He's observed that the smartest people are constantly revising their understanding, reconsidering a problem they thought they'd already solved".
Never was a truer word spoken. We live in an imperfect world and to iterate is human. After all, what is life if not a series of decisions ("the how") made in service of intentions ("the why")?
Most of us live our lives according to a set of overarching intentions: to be a good friend, a faithful partner, a nurturing parent, an effective manager, and so on. Over time, the decisions we make in service of these intentions evolve and improve as we learn more about ourselves, the world around us, and the people we share it with.
There are many parallels with software development, where the debate between exponents of different Agile methodologies ("the how") continues to rage. Agile, Lean, Iterative, Scrum, Spiral, Extreme, Kanban, the list goes on. Every man and his dog seem to have a preference, and rarely do they agree.
One widely-read article on the UX Collective blog declared: "Stop delivering software with Agile — it doesn’t work"; while entire books have been dedicated to how Scrum is the saviour of the industry.
Let’s Re-Frame the Narrative
The debate shows no signs of waning; however, we believe "the why" is more important than "the how".
What many commentators overlook is the need to honour the intentions of a project during design and development. Without a clear framework to guide the decision-making process, no amount of chin-stroking, debating or arguing over "the how" will result in a solution that truly delivers on "the why".
For every major project we undertake at Smudge, we document a set of intentions, which become the guiding principles for every decision we make. Throughout the life of a project we use iterative development to create and iterate solutions in service of those intentions.
For example: when we set out to create the OnDuty app for New Zealand Police six years ago, our team undertook a period of observation in order to define a set of core intentions; and while we've iterated those intentions along the way, they still govern every decision we make.
We intend to follow platform conventions and police conventions to promote intuition over training. Knowing how to complete one action in OnDuty should provide enough context about how to complete another.
OnDuty is used in situations where "eyes up" are important. We intend to minimise interaction to push users through workflows quickly, so they can maintain situational awareness.
OnDuty should be a tool that lets frontline police work effectively with their unit and their team.
OnDuty should transform and enhance, not just replicate. OnDuty should enable a better future, not simply move pain points from paper to mobile
OnDuty is only as strong as its weakest part. While there will be multiple features being built at once, OnDuty succeeds and fails as a whole.
OnDuty should be the easiest way to get a job done.
A frequent criticism of any Agile-based methodology is that the lack of a big picture vision can cause chaos, resulting in Frankenstein solutions and the team building themselves into a corner, two weeks at a time. Naysayers claim that Agile projects tend to be vague, nebulous and difficult to track. And yes, all of this can be true if the overarching intentions are unclear.
Going back to Amazon, it's well documented that the Amazon Web Services team have devised an ingenious technique to help guide their iterative process. Before starting development, they write a press release and FAQ document for the hypothetical future product.
This allows them to debate the positioning and potential customer impact of a product before they write a single line of code. In doing so, they are creating a North Star for the creative process, which according to long-time AWS leader Andy Jassy "helps with rapid iteration and keeps the team on track".
Balancing Competing Intentions
This probably sounds all well and good but there's a catch: since we're humans designing solutions for other humans, we often run into competing intentions; and balancing those intentions can make or break a project. For instance, one intention might be to design an app that is fast and fluid, while another might be to bring it to market as quickly as possible.
We are acutely conscious of this, and try to leverage competing intentions to create balance. While this is not always easy, we constantly strive to create solutions that balance usability, viability and feasibility.
At Smudge, we don't just use intentions to help deliver products. We put intentions at the centre of every decision we make. For instance, we have intentions that help guide strategic business decisions, as well as hiring and onboarding employees, and many other cultural elements.
Ultimately, we want to grow ourselves and each other. In order to do that successfully, we need to act in an "agile" way but this needs to be guided by a framework of intentions.
Like Bezos, we acknowledge that it's not just okay to change tack from one day to the next, it's actively encouraged (because that means we're learning and growing). We reserve the right to change our minds if it helps us make better decisions in service of our intentions. Think of it as strong opinions, loosely held.
Designing and building software is more art than science. The trick is looking for joy in the trade-offs and finding beauty in the balance.
To solve problems in the most effective way, we rely on intentions. They help guide how we work and interact with our customers and each other.
The worlds of design, consultancy and software engineering are colliding, with big implications for the creative services industry.