:quality(90))
It is said that anyone ever involved in setting up a process of managing software development had an idea of coming up with his own custom tool and workflow. Specifically in web software development.
We’ve all been there. We’ve gone through all existing tools and, this way or another, found our best shot. Heard of kanban? It’s as easy as 1–2–3 to tear it into pieces, take what fits, and call yourself agile. Daily inertia inside a busy software house hive has proved it all right.
In our line of business, we work on various projects simultaneously and have to stay ABC at all times, therefore well-optimized workflow is a must. It’s also a moral boost and sanity check for developers. Top-down and bottom-up — both have to meet.
Because there is as much to it as a human factor is concerned as it is to a business requirement. And yet, maturity of the workflow defines the team. We almost take it personally. We’re still in the process of getting the most out of ourselves. And we’ve come to a milestone where we are happy.
We use Trello for project management. We’ve developed a management workflow that is spread across different boards and more or less kanban-like. Sounds familiar?
Lords of the boards
Lots of inspiration for our workflow comes from the approach described by the makers of UserVoice. As it did for their team, the openness of Trello allowed us to figure what was best for us. At the same time, it still allows for some small organic changes throughout different projects — small enough for anyone within the team to immediately grasp what is happening in the project even if he’s never worked on it.
That is why it’s more like a template that proves best.
Product/planning board
This is the place where stories are gathered and requirements get written down. A meeting point for product owner and project manager. The board features the following columns:
-
Ideas and feature requests,
-
Story is considered useful, required specs are being created,
-
Specs are approved, designs are being prepared, estimates required,
-
Finished user-stories,
-
User-stories for a next sprint.
Development board
The board is specifically created for developers with clear order of priorities:
-
To do — tasks in current sprint ordered by priority.
-
In progress — when I start working on something I move my card here. Only one card assigned to one person. Does this ring a bell?
-
Ready to test — a story that has been delivered to staging server.
-
Tested and ready to be deployed to live — party that is at the end of the pipeline moves the card here (the QA process).
-
Live v[x] [date] — for each live release with a date attached. We keep up to 3 versions, the rest is archived.
How it works
All stakeholders have access to all boards: The client, project managers, developers, designers. This has obvious advantages. First and foremost — cards can be moved freely across boards, and the whole history is visible to everyone. Turns out that a requirement isn’t specified precisely enough to be implemented? Take the card back from the development board to the planning board for more feedback. Having two transparent boards also gets some burden off the client’s head — he does not necessarily have to be involved in development process, however he can check the progress of each story any time.
Cards represent stories. Simple. We’re not nazi in this regard, but whenever possible it’s best to create cards as stories. If a story turns out to be too big — split it into multiple cards.
Describe stories by checklists. Each card has a checklist that represents specific tasks to be accomplished to finish the story. Each item on the checklist mentions the person responsible for each part of the story. We found it is sometimes a good idea to group the checklists e.g. into front-end tasks and back-end tasks, especially if there are lots of them.
Cards are attached to people involved in the task. Remember to keep those people actively involved in the card who assigned to it. If someone finished his part, he detaches himself from the card.
Mention! There is never too much to stress that mentioning is powerful both on system as well as on human level. Calling someone directly means they will get a notification. You need a specific person to pay attention at some specific point. Finger pointing when things are on the move, not after a failure.
Where the wild things are
The above are the foundations. There are more quirks.
For example, we came up with a “Release tasks” label. It should be applied on a card that needs some extra work to be done during the release, like “execute a server script.” The release checklist should be created next to it with all the activities to be performed listed.
You can get creative. Give it some thought. Describe your internal processes and apply that in Trello. You can use labels and titles of the cards as metadata carriers. They are ambiguous enough to always feel natural. In the end this is what matters the most: to keep it real.
Hopefully, some of these can be helpful to anyone out there struggling with the development process. Some of these may as well become outdated in a year from now. And that’d be fine — it would mean we’ve evolved again. And you could expect to hear from us about what we’ve learned on our way, too.
:quality(90))