Agile project management as we know it

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.

JVRP Codifi Product Backlog

User Stories, or what the project really is 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!

5 Comments

  1. Russell Alleen-Willems

    Scrum/Agile is an incredibly powerful tool for getting things done and working as a team. Many of my friends who work in tech use versions of Agile daily and I’ve wondered if it would be a good fit for archaeologists given the need to communicate across a number of people and split up complex projects into doable chunks. Congrats on implementing it at CoDA! I hope others follow your example and considering trying it in both archaeology departments/office and on field projects!

    Reply
    • Elena Toffalori

      Thanks Russel! We definitely see it as a great tool for bridging these two worlds. And as you say any team can make up its own ‘version’ and adapt to its existing workflows and needs.

      Reply
    • Michael Ashley

      Thanks Russell. I actually think archaeology may be an agile process… As we tack and jibe, test and retest assumptions both in the field and post. We hope this sparks a conversation about the merits… and the pitfalls.

      Reply
  2. Adrian Pyne

    Ah the usual mistake, this is Agile Development NOT Agile Project Management. Its no wonder so many organisation screw up Agile PM.

    Reply
    • Elena Toffalori

      Thank you for your thoughts Adrian, our development teams do agile work as mentioned in the post, but we think the core topic here is just how we coordinate and communicate between team members! Agile (development) was and is a source of inspiration to us!

      Reply

Submit a Comment

Your email address will not be published. Required fields are marked *

Written by: Elena Toffalori

Mar 2, 2015 | Tips | 5 comments

More Articles

Five Lessons from Hiring a Freelancer Online

Freelancer Developers can be an affordable option for small teams or projects with a tight budget. CoDA tested out Upwork, an online hiring platform, last year and worked with a few freelancers, some better than others! Here are 5 things we learned and how you can get the most for your project on a budget of any size.

read more

Moana: Ancient Folklore Goes Digital

For the ancient Polynesians, folklore was shared by word of mouth, today the most popular platform for telling stories are movies. Moana, Walt Disney Studios’ latest film, tells the story of a young girl raised to become chief of her people who comes to discover she...

read more