At PromptCloud, we follow a Scrum-but process and use Redmine, a neat project management tool, to support it. The basic version of Redmine is open-source and written in Ruby and can work on any machine that supports Ruby and that’s linked to some database. Its however quite strict in terms of compatibility with the Ruby version and its gems and takes time to get the nuts and bolts right, but once installed the Redmine journey is very smooth.
If you have used a Scrum-based tool in the past, you probably know how any such tool forces Scrum on you. It then turns out to be quite useless if you aren’t following the process word by word. Although that’s not a good thing to do in principle, you can’t avoid adding some ad-hoc-ness (if you are a startup) to your process which apparently makes more sense in the short-term, especially when it’s something to do with the client. Redmine fits in perfectly well without adding bureaucracies and you can make it work for your needs- irrespective of the team size, process or the project types.
As you would expect from any other project management tool (commercial), Redmine is quite self-sufficient in itself despite being open-source. You can basically create as many issues with task types of bug/feature/task and assign it to a member, input start and end dates, estimated time, give it a description, etc. You can thereafter track its status through your customized statuses by simply updating it accordingly. The complete history on an issue can be tracked from a single page.
All such issues (and their sub-issues) can belong to a project, which itself can be a sub-project to another higher level project in the hierarchy. You can create as many users as you like and specify their access levels. A user can then be assigned to a project after which she can be added to any task under that project; either as an “assignee” or as a “watcher”.
You can also add files to a task as well as track what percentage of the task is done. Text formatting within Redmine works like any other Wiki. All activity for a sub-project or the entire project can be tracked using the “Activity” tab which shows all issue updates in an intuitive manner and you can go back in history until the beginning of that project.
Various Redmine plugins are out there which you can install for any specific use that might come in. Again, you have to be extremely wary of the compatibility of these plugins with the version you operate.
Below are the Redmine pieces we have brought to our use.
We leveraged the “Target Version” component here to do our weekly planning. We named a version as “pool” which holds
all the anticipated tasks in the pipeline. During the weekly planning meeting, tasks from pool get pulled into the current version which runs for a week. Two weeks might look more viable given the standard sprint lengths, but our model is such that we don’t have much visibility into client requests that may arise.
Each team member self assigns tasks for the week based on a combined notion of roadmap. We make sure the following fields are input- task description, assignee, due date and duration. Here’s a glimpse of how each task (either already in pool or in creation) gets assigned to a version.
Redmine does best what it claims. It’s essentially a tracking tool for bugs, feature updates or whatsoever is easy to miss or crucial to track. Once a task / bug is created, it stands strong as a perfect reflection of what has been happening with respect to that task. You have additional options to log time against each task. You could also use the checklist feature to create a list of items within a task to later strike off without having to create sub-tasks. We use New -> Assigned -> Resolved -> Closed (Feedback, WaitingonClient and Rejected are other status types) as a transitional flow for any task.
We practice near real-time updates to tasks in Redmine and have integrated such updates to email in lieu of which, all watchers of the task receive email notifications whenever an update occurs.
All tasks that are complete are marked closed (bonus- Redmine displays the closed tasks with a strikethrough) and those that are yet to be worked on are pushed into another version called backlog. P.S. The due date is unchanged.
Our weekly meetings usually start with a postmortem of the last version where all closed and pending tasks are discussed along with the roadblocks that came in. The idea is to do a general analysis of what went well and what needs improvement. Such discussions emit a lot of improvement tactics as by-products- both in terms of using Redmine or changing our internal processes.
1. Wiki- What you are bound to use if you use Redmine is their Wiki. It comes so handy that we sometimes cheat by updating the wiki page for the weekly meetings without updating tasks and are still done ) (not a good idea for future tracking though). We also use this wiki for all things A to Z – be it MoM, notes from a strategy discussion or even a structured training handbook for new joiners. Moreover, complete documentation of our technology stack sits there.
2. Integration with Gerrit – We use git as our code repository and gerrit for the reviews part. We have customized Redmine to work with Gerrit wherein all code reviews related to a task get updated within that same task on Redmine by simply specifying the task ID while committing our code.
3. Support portal – This is more of a secret than an essential because a lot of sweat has gone into making this work, but yes, we use the same instance of Redmine as a support portal where our clients can open tickets and assign it to us and we consequently get notified of the same via emails without having to log into the tool. What’s better, we simply copy these tickets to our internal project for internal tracking of the WIP. The client ticket is updated accordingly (or rather more professionally ) ).
Each client of ours operates via a sub-project on Redmine where one sub-project can’t see another. However, our team can see activity on all client projects because of their access levels.
4. Relating tasks to each other – This is a simple yet powerful feature that comes across as extremely useful. You can easily relate a task to another to keep track of what else had to be done to close a loop. Pretty neat when you are developing a component and have a dependent task to accomplish.
The usual suspects
Here’s a list of what we sought for in a project management tool and what we got of Redmine.
1. You do not have the ability to create all your tasks or sort of a work breakdown structure in one go. All you can do is create each task, one per page, and assign the parent tasks to children later. There’s no complete view of all your tasks or milestones at the same time.
P.S. Avoid using the sub-task feature because it creates a bit of complexity while tracking. E.g. you can’t close a sub-task without closing the parent task.
2. For the same reason as above, Redmine is not a good planning tool but it never claimed itself to be one. You can however convince yourself with the workarounds.
3. You will notice that over a period the tasks end up in a big blob of irrelevant ones if you have not been very disciplined while updating it.
All that said, Redmine can be used for tracking tasks of as small as a 2 member team without any constraints. It only takes practice to keep it updated and you can always tweak it to suit your needs; especially even for the meta tasks that take up 80% of your time if you are not hands-on. What’s more? It’s open-source so as long as you are willing to put in that effort, stay assured of the feeling of a great management tool for the zero price you pay.
Notes- We recently installed CRM and invoice plugins too and they have been working under the same philosophy as intended above. More on that in future posts.
Have you brought Redmine in action in various other ways? We are eager to hear.