agile ux in an agency environment
TRANSCRIPT
Agile UX – in an Agency Environment
Dan Kalafus @danafus
My first Agile experience
● In-house position● Three interconnected products,
on a quarterly release cycle● Project roadmap planned up to a year in advance,
updated quarterly● Projects went from design to development to QA, then into
integration testing
Then the company went through a transition from Waterfall to Agile (Scrum)...
Waterfall vs Agile releases
Waterfall: Specify requirements, release date
Agile: Can specify one or the other, but not both
● Fixed scope, variable release date● Variable scope, fixed release date
1
2
3
etc.
Bac
kglo
g of
use
r sto
ries
The Agency Environment
“Agency”: A company hired to perform specific work for another organization.● Custom software design and/or development● Might also include product strategy,
advertising/marketing strategy, content strategy, research, user testing etc.
● NOT “staff augmentation” (but might work alongside client staff)○ Often working with larger clients
● Value proposition: Providing a complete team with specialized skills and experience
When an agency gets involved
The idea The pitch The funding
Conflicting interests
Client needs:
● Stay within budget● Guaranteed outcome
Agency needs:
● Costs plus profit
Preference:
● Fixed-price contract
Preference:
● Time & Materials
Agile on a fixed budget
Fixed-price contracts present essentially the same problem as a fixed scope release with a fixed timeline– with the same inherent conflicts.
How can we give the client some reassurance that they’ll end up with something resembling the product they have in mind, within the constraints of their budget?
Disclaimer:
This is not Lean.
● Not every client is ready for Lean, or wants it● Conditions of higher certainty● Multiple levels of approval needed
Agile on a fixed budget
How can we give the client some reassurance that they’ll end up with something resembling the product they have in mind, within the constraints of their budget?
Two approaches:
1. Estimate from high-level designs, agree to fix scope or time/effort
2. Define features loosely, design for iteration
?
?
?
?
Approach #1: Estimate from high-level designs, agree to fix scope or time/effort.
Develop
Coming up with an estimate
First phase (or project) Second phase (or project)
DesignDiscover
Develop Detailed Design High Level DesignDiscover
Detailed Design & Build High Level DesignDiscover
High level design
How much detail is enough?
● Depends on the team● Minimum: Enough detail to estimate the amount of work required
… And an estimate, from the development / QA team.
Deliverables:
● Use cases● High level user flows● Major screens, blocks of functionality● Could be sketches/storyboards, or wireframes, and/or visual designs● Designs "50%-80% done"
“But that’s not Agile!”
...But is it Agile?
It’s not comprehensive documentation, or even a specification of a “final” state.
We’re not committing to those exact designs: it’s an estimation tool, and an initial direction.
And doing some design up-front gives us some additional benefits:
● Lets us design the product from a holistic perspective.● Gives us a chance to engage up front with stakeholders who aren’t
able to be involved at the day-to-day level.
Detailed design & build
Backlog High-level designs
(50-80% “done”)
Story points
This phase begins with:
Detailed design & build (simple view)
UX & VisD
Dev & QA
Sprint 2Sprint 1 Sprint 3
Environment setup and other tasks not requiring
detailed designs
Detailed design & build (more realistic view)
Design tasks
Build tasks
Sprint 2Sprint 1 Sprint 3
UX & VisD
Dev & QA
Dev & QA
UX & VisD
Larger projects: Iterate the design phases
High level design
Design and build
8-12 week iterations
Reprioritize between iterations:
● High-level design: What feature set should be designed next?● Development sprints: What part of the feature set will be built next?
Pros and Cons
PRO: Iterative design process allows greater agility
PRO: Allows you come back and fill in gaps, fix inconsistencies etc.
CON: Restricting possible design paths up front
CON: Can be hard to involve Dev and QA in high-level design iterations
Approach #2: Define features loosely; design for iteration
Define features loosely...
Example: Auto insurance mobile app
The Scope of Work (SOW) contract for this project specified particular features that would be developed:
● Accident checklist● View my insurance card● View my policies● Contact us● My agent’s info● Find an agent● Request a quote
● Make a claim● View existing claim● View my bill● Pay my bill
Design for iteration
Find An Agent – Simple version
Enter your ZIP code, and get a list of agents.
Design for iteration
Find An Agent – Better version
Use your phone’s location services, and automatically get a list of nearby agents, in order of shortest distance.
Design for iteration
Find An Agent – Deluxe version
Use your phone’s location services, and automatically get a map of nearby agents - in addition to a list, in order of shortest distance.
Design the simple versions first – then enhance
● Lets you deliver on the contract early
● Buys you time to design enhanced versions
● Learn which features the client cares about the most
v1
v2
v3
Pros and Cons
PRO: Allows for greater input from Dev and QA
PRO: More “agile”: Design in smaller pieces
CON: Clients hate tearing out code - even to build better features
CON: Three designs per feature = lots of work
CON: Can be risky: Client may not be satisfied with basic versions
PRO: Doesn’t require an initial high-level design phase
Recap: Agile on a fixed budget
1. Estimate from high-level designs; agree to fixed scope or time/effort.
○ Create high-level designs as part of initial discovery phase○ Use high-level designs to estimate effort and involve stakeholders ○ Collaborate more closely with Dev & QA in detailed design
2. Define features loosely; design for iteration
○ Start with minimal versions of each feature○ Add enhancements in later sprints
