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:
- large amounts of unproductive work and
- decreased quality of life at a personal level.
Or, being completed early with:
- the least amount of work possible,
- a feeling of accomplishment throughout the process and
- a sense of belonging and pride.
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!
Things that do More Harm than Good
Group Meetings for Task Reviews 🌪
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.
Automating Everything ⛓
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:
- create hidden actions that must be taught, remembered and documented,
- increase project management complexity and
- become more dependent on the current management technology, making it less likely to ever switch.
Sprint cycles by objectives, instead of periods🚦
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.
Having a Backlog 🗄
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:
- adding these tasks into the current or following sprints and
- to move or discard uncompleted tasks at the end of each sprint.
Things that Usually Work
Clear Reaction(s) for every Action ⚡️
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:
-
OwnershipSince tasks are always owned by the person who’s expected to do specific action(s) with them in order to transfer ownership along the pipeline.
-
Clear personal pipelinesBy being clear what each person must do next allows for more mental capacity on the actual tasks.
-
Non-intrusive progress trackingBy making it easier to identify issues along the pipeline early on and mitigating on them by talking directly with whoever is assigned at the time.
Fibonacci estimations 📈
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).
For example:
- 0: no action needed,
- 1: < ½ hour,
- 2: < 1 ½ hours,
- 3: < ½ day,
- 5: < 1 day,
- 8: < 3 days,
- 13: < 1 week
- 20: < 2 weeks
Note: There shouldn’t be tasks over 8 or even 5 points. If any arise, they should be broken down into smaller tasks.
Obsoleting the need for personal lists 📃
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.
Prioritization 🍱
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 behaviourLive 1: live bug, not preventing core behaviourDev 1: needed for next releaseDev 2: needed the following releaseDev 3: nice to have
Leader(s) / Delegator(s) 👨✈️
Leaders / Delegators are incredibly useful for:
-
Handling development requests and bug reportsThis allows developers to focus on their current task and not get distracted by the constant inflow of requests.
-
Prioritizing TasksBy helping developers pick the next task based on a number instead of it’s relevance to the business’s needs their deliverable productivity increases.
-
**Helping Developers Understand the System**It’s normal and expected that developers will initially not understand the system and even deviate from using in afterwards.So, when leaders detect inconsistencies, they help the developer better align with the system or adapt the system to the developer.
Predictable Communication 👁️🗨️
A common reason why people dislike management systems is that they have too much information.
Very effective ways to reduce the noise are:
-
**A pattern for creating and commenting on tasks**Having a common format makes texts much easier to absorb.
-
Expected comments on task state changesexample: when moving a task from done to QA a comment should be left explaining what should be tested.
Concluding
Effective project management results in:
- greater output,
- a collective feeling of accomplishment,
- and less stress.
It suffers from:
- unproductive meetings,
- hidden automations,
- objective based sprint cycles and
- eternal Backlogs.
And benefits from:
- task lifecycles with clear expected actions from specific people at each stage,
- protection from biases in estimations,
- being appealing to developers,
- leader(s) / delegator (s) and
- reducing noise during commutation.
Keep in touch
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).
A little Thank You to those who I learned from
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.