Getting stuff done is an art, getting a team to get stuff done is a symphony of egos, habits, and skillsets.
The optimal management system is usually right around the corner. But because of small mistakes, it can seem unreachable.
These mistakes, however, can usually be solved without meetings or more than a few messages on slack.
A well-tuned project pipeline can be the difference between it getting completed in 10x the time, causing:
Or, being completed early with:
So I gathered a very summed up list of lessons learned and methods that I have seen work very well. Hope you learn something new!
These usually just result in a bigger mental burn than actual development, not covering all tasks and misinterpretations due to lack of time.
A solution to this is a task pipeline with QA (quality assurance) steps, where tasks are reviewed independently when ready.
example: when a Pull Request has a specific keyword and/or a task ID the task is auto dragged into Review
This, at first sight, seems great and is very appealing to developers, however, what we do when setting up these automations is:
Some companies deal with uncompleted sprints by delaying them into the following weeks.
However, this can turn into a vicious cycle that results in big amounts of stress for the whole team.
It’s much healthier to stick to the cycles on a per time basis. So if a print reaches the last day and some tasks are not complete they can be re-evaluated and moved (or not) into the next sprint.
Continuously dumping feature requests and bugs into a single Backlog makes it very time consuming to consult and allows for these tasks to remain there for eternity, forgotten and burdening.
A more effective approach is to have a process for:
Tasks should follow a clear cycle, where at each moment it’s clear who’s expected to interact with it.
Sticking to this rule allows for:
Estimating on how long tasks will take is incredibly prone to biased predictions.
A system that I have seen greatly help with this is to assign a difficulty to each task based on a Fibonacci scale (a.k.a. Planning Poker).
Note: There shouldn’t be tasks over 8 or even 5 points. If any arise, they should be broken down into smaller tasks.
A golden indicator for when a management system is well integrated is when everyone uses it on a personal level for even the smallest tasks or side tasks.
Of course, forcing people to use it is not how this is achieved. It’s by making sure the system is truly simple and convenient for personal use.
It’s very common that the number of tasks that we want to fit into a sprint is overly ambitious, and that’s healthy if dealt with well.
A very simple way to ensure that what’s important gets done is assigning priority to tasks.
I have had a good experience with this system:
Live 0: live bug, preventing core behaviour
Live 1: live bug, not preventing core behaviour
Dev 1: needed for next release
Dev 2: needed the following release
Dev 3: nice to have
Leaders / Delegators are incredibly useful for:
A common reason why people dislike management systems is that they have too much information.
Very effective ways to reduce the noise are:
Effective project management results in:
It suffers from:
And benefits from:
I write in the interest of meeting people with whom to have interesting conversations with. So I would like nothing more than the get a message from you in the comments or on twitter (@esperancaJS).
I would not have learned many of these topics without having been blessed with getting to collaborate with great companies such as Beamery, Altar.io, Innowave, and more recently, NearSt.
Thank you, Michael, Kent, Daniel, André and Adam for putting up with me and for all your wisdom.
Create your free account to unlock your custom reading experience.