Frameworks in project management Waterfall – linear, non-iterative Spiral design process -- iterative Agile development Scrum Product backlog

Waterfall Constant “downstream” flow Solves problem of “requirements churn” by freezing them Creates problem of momentum—cannot backtrack when we find problem in original requirements or design concept

Waterfall fails at iteration Requirement specifications change as functional analysis reveals new information: “now I see the user needs to specify colors of beads, so we designers need a color chooser” Design Functional Analysis changes as design reveals new information: “now that we have a color chooser, we see “Black” which is a bad luck color for Ute native americans, and a good color for the Shoshone.”

Waterfall fails at iteration New Requirement specifications “Use a color palette so that users have the option of choosing without “naming” the existence of black beads.

How to deliberately incorporate iteration? Requirement specifications change as functional analysis reveals new information: “now I see the user needs to specify colors of beads, so we need a color chooser” Functional analysis changes as design reveals new information: “now that we have a color chooser, we created a problem with cultural fit”

Spiral Design Process Minimizing project risk by breaking a project into smaller segments Perform same cycle each time: Analysis of goals and constraints Evaluation of options Development and feedback on deliverables Plan for next iteration

“what needs to be on our radar screen”? SWOT analysis Can be used during spiral design process at any point, often useful just to ask “what needs to be on our radar screen”?

Google Charrette  Jan 2014, Mountain View CA: Designing Google’s diversity computing initiative.

Google Charrette Context: what different situations might we imagine as the context? Scenarios/use cases: note division between “pull” (their interest) and “push” (our efforts)? Functionality: requirements follow from use cases.

Google Charrette  Review: What formative evaluations will be needed to keep the design process moving forward? Parking lot: stuff we can’t deal with at the moment but will clearly need to be revisited.

Agile methods Break tasks into small increments with minimal planning Iterations are “time boxes” or “sprints” -- typically one to four weeks. Cross functional teams: planning, requirements, design, implementation, testing Team has responsibility of self-organizing – not controlled by hierarchy Daily Scrum: Sprint is long cycle, scrum happens short cycle If multiple teams, one representative from each attends scrum In addition to teams: Scrum master – “servant leader” to remove obstacles Product owner – voice of customer or stakeholders

Product Backlog Features, functional requirements, bug fixes, etc. - whatever needs to be done Typically the Product Owner organizes – often use concept of “stories” Story from one stakeholder “As a user I want to be able to search for my clients by either first or last name; I don't always know both.” Different story from different stakeholder “As an admin I want to be able to look at client searches by users, but I don’t want clients to be able to do that.”

Product Backlog A product backlog can help us reflect on sources of requirement mismatch: did we fail to specify this properly, or did the technology fail on what we correctly specified?

Product Backlog Prioritize by attributes such as value to customer and development effort – if something has a small development effort requirement, then higher the ROI (Return on Investment). In some cases this can be intuitive: