Agile UX in an Agency Environment
4 likes1,056 views
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.
Agile UX in an Agency Environment
- 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