A Lightweight Project Management Workflow
Every time I start working on a new project where the means of coordinating the software development work are not established yet, I propose a lightweight agile workflow distilled from my past experience on a wide variety of projects. This workflow described below is my personal preference and by no means perfect or the only feasible approach. Also nothing here was invented by me.
The workflow is best applied at small teams of 1-10 people working on a single software product. Ideally, the team is composed of one or more developers with roughly similar skillsets, optionally supported by one or more visual/UX designers.
It is also useful to have one person appointed for “running the show”, which means this person is responsible for making sure the agreed upon process is followed and adjustments are made whenever necessary. This role can be taken by the same person for indefinite time but can be periodically rotated as well since it does not require special skills other than knowing this workflow. (In more formal Scrum projects this role is called Scrum master).
The board
The center of this project management approach is the agile board with three swimlanes or columns: ToDo, Doing and Done representing the state of the stories contained within the lanes. The swimlanes contain stories represented by cards or sticky notes. Stories can represent development or design work, new features, improvements, bugs or maintenance tasks. This is also known as Kanban board.
There are no hard constraints on how a story should be phrased and what it should contain but there are a few practices I recommend:
- Keep the amount of work per story small. Preferably not more than one person-day per story.
- It is OK to add larger stories to ToDo but break it down to smaller ones before the actual work starts.
- Be clear when phrasing a story. Use imperative style for new features and improvements (use the words “add”, “create”, “make”, “improve”, etc.). For larger features it might be useful to start with “user story style” optionally followed by detailed requirements.
- When adding bugs to ToDo, make sure the distinction between the intended and actual behavior is clear. “Expected the icon to be cornflower blue but got red” is better than “Button is red”.
The rules
This is the team’s daily workflow. Tweak according to your needs.
- Planned and committed-to stories are in the ToDo column.
- The next story to work on (often but not always the most important one) is at the top of ToDo, the last one at the bottom.
- ToDo stories should not be pre-assigned to a person, anyone capable working on the next ToDo should be able to take it.
- When someone starts working on a story, it should be moved to Doing.
- Ideally nobody should be working on more than one story.
- If something gets blocked, better move it back to ToDo.
- Once a story is complete, it moved to Done. For most stories “done” means tested and deployed to production.
If the team does daily stand-ups to catch up, it is a great opportunity to ensure the agile board reflects reality. Even if stand-ups are not practiced (very small team or solo developer, cross-timezone collaboration) it is useful to (only) refer to stories that exist on the board when discussing progress.
Besides the daily routine, some teams work in sprints or iterations. In this lightweight workflow it is not necessary to stick to a rigid schedule, however I find reflecting to past progress and planning ahead every once in a while useful.
The tool
The agile board has to manifest itself in some physical or virtual form. Choose the simplest tool possible. If you are a small team all sitting in the same room use sticky notes on a reasonably sized wall surface. If a digital approach is preferred, go for a tool that has the smallest amount of features necessary. Bloated all-inclusive solutions like Jira only result in tears and fist-shaking. I recommend Trello, Pivotal Tracker or when using GitHub or GitLab for source code control they both both offer decent Kanban-like boards. See GitHub’s project management offering and the one of GitLab’s.
Conclusion
Every project needs some structure but keeping the process lightweight for small projects can reduce overhead and friction. If the team or the organizational complexity grows later, there is always to option to “upgrade” the workflow to something more sophisticated.
What is your favorite lean workflow? Can it go even more lightweight than described here? Should it? Let me know what you think!