On Agile
From the various Agile-related concepts, I'd like to highlight two:
- It meant to combat requirements volatility (frequently evolving or changing requirements or their priority).
- It increases time to market.
Agile, when used in the right context (and followed by the word), is nothing short of magic. The cost of changes within a properly managed Agile project can be dramatically lower compared to the waterfall paradigm.
But Agile is not a catch-all solution (what is?), and sadly it is often seen as a silver-bullet that will always work. The reality is far from that.
On requirements engineering
It has been known for years that the sooner a requirement is accounted for in the production process (Requirements, analysis, design, coding, unit-testing, deployment) the less costly it will be to realise - changes are cheap at the beginning of the process, very expensive at the end.
This is something that every software/UX designer will testify - the more of requirements you know of before the design process, the more solid the design will be.
There seems to be a contradiction here - on the one hand, Agile preaches to short iterations of highly limited scope (including what requirements are accounted for); on the other, the more requirements you account for, the better the designs.
The 3 design strategies
There are basically 3 design approaches (UX or software):
- Throwaway (revolutionary)
- When you have little understanding of the problem and requirements (high level of uncertainty)
- You design quick, test quick, and mainly to learn what works and what not.
- Normally a super-quick process, but designs are likely to be discarded (leading to redesigns or rework).
- Evolutionary
- When you have some understanding of the problem/requirements, but it is incomplete and likely to change.
- You build the design step-by-step, accounting for new knowledge in each iteration.
- Designs typically serve as basis for next iteration.
- With each iteration the previous design often requires revisions - sometimes dramatic ones.
- The danger is that bad designs may persist.
- Incremental
- When you have clear understanding of the problem and requirements.
- You design to meet all requirements.
- This process can be long.
When Agile is great
Agile is great for a project where you have either no or little understanding of the problem domain. For a completely innovative project, the throwaway strategy is often used; however, most Agile projects use evolutionary design. An incremental design is generally anti-Agile.
What is important to mention is that using Agile must come with the realisation that your current design may not fit future requirements. It's what you've signed for by choosing Agile! This is why code refactoring is absolutely vital to the success of an Agile project. In Agile terms, you knowingly deliver just enough; nothing more. It will work for now, in the future revision are likely.
When Agile is a disaster
When you have a clear understanding of the domain problem and requirements. You'd be generating a lot of waste and rework by not accounting for these from the onset, and by not taking the longer, non-Agile incremental design.
Quite a few companies have a clear understanding of the problem - the system has been there and used for a while, with all functionality in, but usability is low. So it'll be rather dubious to ask designers to ignore evidence, just so the work can fit into a 2 week sprint.
Suggestions
To begin with, it may be the case that your peers are trying to eat the cake and leave it whole - you can't be asked to produce optimal designs unless you are given the time to look into all requirements. The concept of just-enough-now-iterate-later is key to Agile.
Then, you can obviously try to look more laterally on other parts of the system so at least to get some idea of what is ahead.
But all in all, I'm sorry but I don't think it's fair to ask someone to do iterative design that by definition does not account for all requirements, then complain that the design needs changing because it doesn't account for all requirements.
