The Design Manifesto: How agile is as much about design as it is about development.
I’ve been working in design and IT for around 5 years, along the way, I have been a passenger in the fields of agile methodologies with teams using various levels of SCRUM for IT delivery, Kanban for design work and a fly on the wall for the development of DevOps.
Emerging from the fields a few inherent commonalities presented themselves. Overall no matter the methodology, the discipline or the framework they all are concerned with answering questions about how humans work together like How do we work effectively as a team?, How do we deal with the differences in approaches and language that the collaboration of multiple disciplines presents us with? or How can we test solutions as fast as possible to maximise learning to deliver value faster?
If you’ve been around tech at all in the past decade you would have heard of agile. The agile manifesto is a set of principles that was released in 2001 to guide the future of software development. These principles emerged out of the mass frustration that was developing from companies that were so focused on excessively planning an documenting their software development that they lost sight of who they were making software for. (If you want to see the original agile principles see here https://agilemanifesto.org/principles.html)
Whilst agile working originated in the software development field it is not solely a development practice. If we remove the software development specific wordings from the agile manifesto set of 12 Principles we get a set of principles that is suspiciously close to the principles that have developed over the past few years of User/Human-Centred Design and Design Thinking.
I present you.. *Drum roll* … the agile manifesto.
The Agile Design Manifesto
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable services.
2. Welcome changing requirements and insights, even late in Design. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working insights (Learnings) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and designers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a design team is face-to-face conversation.
7. Agile processes promote sustainable development. The sponsors, designers, and users should be able to maintain a constant pace indefinitely.
8. Continuous attention to technical excellence and good design enhances agility.
9. Simplicity — the art of maximizing the amount of work not done — is essential.
10. The best insights, research, and designs emerge from self-organizing teams.
11. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
12. Customer behaviour (Outcomes)is the primary measure of progress.
Now, much of these seem to align quite closely with many of the principles for Design Thinking, User-Centred Design, Human-Centred Design etc.
I believe at the heart of all of these emerging fields we are all trying to figure out how to work together. There exists a range of principles and practices that lie at the heart of each that connects them together.
This gives us common ground that might show how design will grow in the future and how design and development share a common purpose.
For the next article (whenever that is) lets take a look at putting a design spin on DevOps and see how it matches it’s emerging sibling DesignOps. ;)
Let me know what you think of this article.
