I attended Agile UX SIG #2 last night at the ThoughtWorks where agile geeks met to discuss the much hyped Agile methodology. While I’m curious about all the fuss I’m also professionally interested to learn how Agile might improve workflow. Further, next year (User Interaction Design MSc) I’m enrolled in a ‘Agile Methodology’ module at university (see below). My hunch is Agile methodology will gather further momentum and become more widely adopted in the future so I need to pay attention to it.
Agile Development description:
This module provides a systematic understanding of the fundamental principles and techniques associated with agile project management, by linking the DSDM Atern framework with the object oriented paradigm through tools like SCRUM. Kingston University, CISM
Anyway, at last nights meeting Matt Roadnight, an Agile Scrum coach, explained how he coaches Agile Sprint methodology with business teams (his clients). Essentially there are three overlapping groups: Project Owner, Team Members and a ScrumMaster. Every project has what’s called a ‘Backlog’ – a set of items that must be designed/developed to progress the project. The project undergoes continuous flurries of meetings, or Sprints, where these backlog items (or groups of related and timely) items are discussed. Future items requiring attention are discussed in sprint planning meetings too.
Role definitions and responsibilities
Matt went on to define roles and stressed the importance of collaboration and communicating amongst each other he defined responsibilities. The Project Owner – typically a senior stakeholder – is responsible for the Vision which includes strategy, business case, user experience research, as well as ROI. The Analyst is responsible for the Features and finally the User Experience Designer is responsible for the Experience. While the Analyst may be a stakeholder too, the UED is customer facing. I might add at this point that there was a little push back from the attendees arguing that user experience and features should not be seen as separate activities… they should validate against each other.
Matt spoke about trying to group backlog items into related groups or Themes which focused on an particular aspect of the design. They are made up of units of User stories. A typical ‘story’ might look like this:
“As the <USER ROLE> I want to <PERFORM FUNCTION> so the <BUSINESS REASON>”
The next Agile UX meeting (in ~6 weeks time) will include a practical hands on 2-hr session walking through a typical lifecycle of an Agile project.