The document discusses the transition from a waterfall to an agile approach in an agency environment, highlighting the importance of managing client and agency interests while delivering projects within fixed budgets. It outlines two key methodologies for agile implementation: estimating from high-level designs for fixed scope or time/effort, and loosely defining features to enable iterative design. The document stresses the benefits of upfront design to provide direction and stakeholder engagement, while also addressing the challenges of managing expectations and coordinating development efforts.

1. Agile UX –
in an Agency Environment
Dan Kalafus @danafus

2. 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)...

3. 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.
Backglogofuserstories

4. 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

5. When an agency gets involved
The idea The pitch The funding

6. Conflicting interests
Client needs:
● Stay within budget
● Guaranteed outcome
Agency needs:
● Costs plus profit
Preference:
● Fixed-price contract
Preference:
● Time & Materials

7. 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?

8. Disclaimer:
This is not Lean.
● Not every client is ready for Lean, or wants it
● Conditions of higher certainty
● Multiple levels of approval needed

9. 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
?
?
?
?

10. Approach #1:
Estimate from high-level designs,
agree to fix scope or time/effort.

11. Develop
Coming up with an estimate
First phase (or project) Second phase (or project)
DesignDiscover
DevelopDetailed DesignHigh Level DesignDiscover
Detailed Design & BuildHigh Level DesignDiscover

12. 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"

13. “But that’s not Agile!”

14. ...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.

15. Detailed design & build
Backlog High-level designs
(50-80% “done”)
Story points
This phase begins with:

16. Detailed design & build (simple view)
UX & VisD
Dev & QA
Sprint 2Sprint 1 Sprint 3
Environment setup and
other tasks not requiring
detailed designs

17. Detailed design & build (more realistic view)
Design tasks
Build tasks
Sprint 2Sprint 1 Sprint 3
UX & VisD
Dev & QA
Dev & QA
UX & VisD

18. 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?

19. 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

20. Approach #2:
Define features loosely; design for iteration

21. 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

22. Design for iteration
Find An Agent – Simple version
Enter your ZIP code, and get a list
of agents.

23. 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.

24. 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.

25. 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

26. 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

27. 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

28. Thank you!
Dan Kalafus
Twitter: @danafus
Email: dkalafus@gmail.com