What does "Agile" mean for design?
There is still a lot of confusion around what "Agile" means in terms of software development. There is even more confusion now that Lean has been popularised. Agile is really not a complex thing to define, in fact the Agile Manifesto does it perfectly: 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.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Things to debunk when you hear them:
- "We don't do the full Agile thing, we pick the bits that work for us" - the Manifesto is non-negotiable. If you're not following these principles, you are not being Agile. You might have very good reasons for doing so, but it's still not Agile. There are degrees of Agility though...
- "We are Agile we use Scrum and Kanban and <insert tool here>" - Using tools developed for the Agile team does not make you Agile, in the same way that buying a Chris Boardman bike does not make you a world class cyclist.
- "Agile is a process/method/framework" - Agile is a philosophy
- "You start with the backlog" - You start with creating the backlog
- "Agile is faster" - Not necessarily, it takes the time it takes
- "Agile scales naturally" - Not necessarily, in some cases it can be very hard to scale
- "If you use heavyweight tools, you can't be Agile" - You can still be Agile and use Prince2 for example
- "You're either Agile or waterfall" - It's not a binary choice, there are degrees in between
- "It's always the same Agile environment from project to project" - Needs will change according to the team so let them structure their environment
- "You can't do Agile with remote teams" - Yes you can, you need to create a working environment (even if it's virtual) that works
- "Agile means you never have to write documentation." - You will need to sometimes, it's about having just enough
- "Agile is simple" - It seems deceptively simple when you read the manifesto, but it takes time (and patience) to put in place
- "You can learn Agile from a book" - Nothing teaches you better than being part of a truly Agile team
What about Design then?
The Agile manifesto mentions design once, around self-organising teams. Having design as an integral part of a software delivery team is new to a lot of companies, and there are still a lot of problems in teams around how to work with the designer. Designers are not all the same: they have different strengths, come from varied backgrounds, and have more or less experience with software teams. While some of them will be a good cultural fit for software, others will struggle. If you have been trained to have ego about your work, and to never show anything until it is perfect for critique...then Agile is going to be a big change.
Lindsay Ratcliffe wrote a manifesto in her book "Agile Experience Design".
Agile Experience design is:
Inclusive rather than elitist
Emergent with direction rather than upfront
Integrated and collaborative rather than handed of the fence
Considerate of customer, business and technology needs rather than biased toward a single factor
I see this manifesto as supplementing the original Agile manifesto. Striving to uphold these values and ironing out the creases is all part of the fun, all part of learning what works and what doesn't. Different teams need different tools, processes and people. What works for one may not work for another even if the circumstances are similar. These manifestos help us stay true to Agile, when we have decided to adopt it. How you go about that is another matter entirely!