Agile Project Management As We Know It

Author: Elena Toffalori

modular-codifi.0011-1080x675.jpg

At CoDA, we are enthusiastic followers of the Agile movement, proposing it as an alternative to traditional project management. Here we give you a short overview of Agile’s basics and two core concepts, user stories and scrum meetings, that revolutionized the way we think through and execute our projects.

Agile Project Management Basics

Agile was originally designed for software development, which is an integral part of our work. We use Agile both in developing and maintaining Mukurtu.net tools and services for web archiving and publishing of digital heritage and in designing custom database solutions and data and media management workflows in our Codifi projects with archaeologists around the world.

But over the years we – and many others – have tweaked the process to extend it to less traditional projects.

In brief, working with the agile methodology means:

  • Focussing on short iterations called ‘sprints’ of work, each delivering a working product increment;
  • Scheduling regular team check-ins (stand-ups or scrum meetings) to maximize the exchange of relevant information while saving everyone time;
  • Breaking project down into user-centric ‘stories’ that translate to tasks;
  • Keep tasks assigned, estimated in hours/days and prioritized into a product backlog.

Read more here about the Agile methodology, originally designed for software development.

 

Product backlog can be a physical whiteboard; we find it convenient to use project management tools that offer ‘whiteboard metaphors’ such as Pivotal Tracker or Jira Agile. You will find plenty of these online, most offering either a trial limited in time or a free plan for small projects.

 

A Screenshot from one of our projects in Pivotal Tracker

A Screenshot from one of our projects in Pivotal Tracker

User Stories, What the project is really about

User Stories are a way to break down even the most complex project into communicable, measurable bits.

User stories are generally built with the following structure:

As a(n) “x” I want to be able to do “y” (so that “z”)

  • For a technical developer, this structure provides context as to why something is being implemented, as well as aid in prioritizing features.
  • For the client and non-technical stakeholders, having to break down the final product into detailed features helps immensely with designing the final user experience and thinking through all possible scenarios and audiences involved.
  • For everyone, stories quantify time and resources, while keeping the ‘why’ (goals) separated from the ‘how’ (specific tool or process), which allows creative solutions to emerge.

A user story should also have detailed acceptance criteria that assist testing the story before approval.

This is an example of a user story we had in our backlog for the new Mukurtu 2.0, launching this month (March 2015).


As a Mukurtu site contributor I would like to add one or many cultural protocols to my Digital Heritage Item so that I can determine who has access to it.

ACCEPTANCE CRITERIA

Given that I am a Mukurtu site contributor, member of at least one community on the site, and I have identified the parameters under which I want my content to be shared, when I add a Digital Heritage item I would expect to be able to:

  • Only see the communities and protocols to which I have access
  • Share the content to
  1. the community only
  2. publicly and still have the community attribution
  3. one or more communities and choose one or more protocols to fine-tune access
  • Create content attributed to one or more communities and protocols to which I am AT LEAST a contributor AND can decide if the audience for my content must be members of all the assigned protocols, or either of the assigned protocols, pending approval

Execution: Value Everyone's Time

Scrum meetings provide a framework for keeping team-wide meetings short and concise (usually under 15 minutes depending on team size), while communicating effectively, tackling blockers and estimating progress. In interdisciplinary projects, frequent communication minimizes misunderstanding and settles responsibility and ownership issues that may arise over the course of the project.

During daily (or regular) stand-ups, facilitated by a Scrum Master, each team member should quickly go through:

  • work they’ve done since last meeting
  • what they’re working on until the next one, and
  • point out any blockers they’ve run into

Individual meetings to clear blockers, or further discussions on a specific issue, can follow or be scheduled now for a different time, so that no one has to sit through lengthy technical discussions that don’t involve them.

As Wikipedia puts it: “Any impediment/stumbling block identified in this meeting is documented by the Scrum Master and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.”

Have you tried Agile for anything but software development, or working with interdisciplinary teams? Let us know your experience!