Too busy doing the doing to talk about the doing?
As a strategy and design studio, we're all over communications. It's an uninterrupted conversation with our clients, hashing out ideas, working iterations of goals definition, research, wireframes, designs. But when it comes to development, when we put our heads down and get to work, it's all too easy for us in our focused implementation state to just do it and not communicate enough about what we're doing. Of course, this can be disconcerting to the client who has no idea how things are going. And that's a ripe situation for fear, uncertainty and doubt to creep into the relationship, and suddenly a successful project-in-progress can feel troubled, even if it's not.
The simple solution is to give regular status updates, which is something we've always done. Even just saying, "Things are going well" can help. But on long projects, or even in 3-week iterations, repeating that same message ends up being not that helpful. Better to share what you're thinking with regards to planning and project management, and provide updates on development of the various features/backlog items worked out in the strategy and design phases. This transparency in the project management process is even better when updates are more specific.
We have been using Open Atrium, the powerful intranet CMS built in Drupal, developed initially by our friends at Development Seed, now maintained by Phase2 Technology, for our intranet to handle all client-facing communications, documentation, file sharing and issue tracking. It's been a great tool for this. No missed emails lost in the spam filter. No critical documentation lost on someone's hard drive. No mega-emails containing two dozen specific items. (Well, those still happen on occasion, but we now can push those into the intranet to continue discussion.) We love it.
And now we love it even more.
Rethinking Open Atrium
We had been using almost all of Open Atrium's various features: messages, uploads, case tracker, books for documentation, and of course the groups functionality. Almost all of the features. The part that didn't really fit in with our communications strategy was the OA notion of "Projects". Until now.
You see, in Open Atrium, the basic architecture is thus: You have Clients, which are defined by groups, and you have Projects, which are ways of grouping tickets within the group by project. It can make sense for a large organization using OA for internal communications to manage several projects. But for a professional services firm like a strategy and design company, or a software company, or any other kind of company that defines work by time-boxed iterations or sprints, breaking up stuff by "project" may not be that useful. Projects projects projects blah! At PINGV, we rarely have a series of small projects with a client where it would make sense keeping them all together in one group; we tend to do bigger projects, projects that have phases of strategy, design and planning, and iterations of development. And when we have a new large-ish project with an existing client, we just spin up a new Atrium group. Project was that dunsel feature — the thing that for us had no real use. But—
What if we use "Project" nodes to define phases and iterations?
Wash that nomenclature right out of OA
Ignoring nomenclature, and just looking at what "Project" as a functionality in Open Atrium does for us, it provides a way to group tickets into clumps that you can define by anything. If we define those clumps as iterations, perhaps, or phases, we can organize and parse through backlog items, features, questions and other tickets by iteration, while providing some ready clarity as to how and when these items will be taken on. (NB: It's an approach that works only with Tickets, not other node types, but in our mind that's a minor limitation.)
What's really convenient is that Open Atrium provides via UI the means to rename "Project" to whatever you prefer to call it (e.g., "Iteration"). These string replacements, configured in the group feature settings available to site administrators from within each group's space, work almost everywhere in OA. (The "Add Project" button seems to be unaffected even by string replacements defined in settings.php. Something to investigate later.)
Once we saw this potential for grouping issues into iterations, we ran with it.
Defining iterations in Open Atrium
As you can see, the Iteration title is compressed down to an abbreviation or acronym in the icon in the tickets display. "Iteration 1" becomes "I1", "General" becomes "GENERA", and so on. After briefly considering using iteration numbers, which we rejected as too arbitrary, we opted to name iterations by the Iteration release date, or end date (e.g., 08/17 or even 11/10/23), which can be abbreviated in a meaningful way in the Tickets views. This gives our clients added insight into our timetable planning at a glance.
Adding a sortable Iteration column to the tickets view involves a simple override to the default ticket View. (If ever we need to revert that Feature during a site update, these changes are easily re-implemented in a few minutes. No actual data is affected.)
This approach allows us also to focus just on the tickets that are relevant now, without having to sort through all the other tickets that are further down in the timetable, and without having to mark dozens (hundreds?) of individual tickets as "deferred" and then change those as they come available.
The bulk of communications still happens in the individual tickets. Questions, information, updates, concerns, notes can be tied to the ticket itself. New questions and bug reports can also be slotted for attention in a scheduled Iteration. So even though we're grouping our backlog items together, we still avoid the one-ticket-for-8-issues kind of communications that can lead to confusion, frustration and missed messages.
We like this system so far because of this fact that all changes are tracked and visible in each ticket's thread. If we move up a backlog item to a higher priority, we simply do it with a comment and change in iteration designation. This flexibility with traceability provides a nice balance for communicating our planning.
And it's all using stock Open Atrium!
Plan before communicating, and vice versa
I should add that this is not how we do our actual project management. Open Atrium is a great tool for project-related communications. We currently use Brian's recommendation, we tried Liquid Planner (disclosure: affiliate link; go to liquid planner dot com to skip it if you like) for our internal planning. Liquid Planner has an API, and we're considering developing an integration with Open Atrium to allow us to push and pull info between the two. Might be a nice convenience. We do the translation manually now, and while it can take up time on occasion, it also provides an occasion to rethink and re-evaluate, so the manual process does have value.
Feature think, Feature do
Now for the road not taken:
When first considering the challenge of better communicating our iterations plans, I imagined up a very simple Features-based solution using nodes and node reference, which resulted in Open Atrium Iterations. This module works as a drop-in extension to Open Atrium. Not touching any existing Atrium Features, OA Iterations defines a new content type with reference fields to call up tickets (cases), messages (blog posts) and documentation (books) that collectively define and describe an iteration of work. A dedicated view restricts the available referenced nodes to the current group's content.
On Friday afternoon, this seemed like a fine way to communicate our iteration planning. Tickets, as well as blog posts and book nodes, could live on their own, with their own revisions and threads, while the Iteration node would group them into an iteration. Done. Time to relax and prepare for a weekend cleaning the garage.
On Monday morning, however, when I sat down to start defining the iterations for one of our projects, I immediately questioned my own game plan. Open Atrium Iterations was an easy way to define iterations, but making changes would be difficult. What if I wanted to move a ticket from one iteration to another? Yes, this project was never intended for iteration planning, just iteration communication, but even just for communications this approach would mean editing at least two Iteration nodes just to "move" one backlog item. What's more, without implementing Reverse Node Reference and adding that block to one or more Contexts (and thus overriding stock Open Atrium Features), there was no way to look at a backlog item and see what iteration it's slotted for. The simple solution was not turning out to be so simple after all.
And that's when the flicker of the idea described above came to mind. In hindsight, I can smack myself for not thinking of this before. I've been working with Atrium for two years. But I think I got stuck on nomenclature.
Meanwhile, despite our not using it as originally planned, Open Atrium Iterations will remain live on Drupal.org to see if it proves helpful to others. If the Feature can be improved upon to make it more broadly useful to serve more use cases, I look forward to suggestions in the issue queue.