Getting stuff done is an art, getting a team to get stuff done is a symphony of egos, habits, and skillsets. The optimal 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. management 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 list of lessons learned and methods that I have seen work very well. Hope you learn something new! very summed up 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: Since 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. Ownership By being clear what each person must do next allows for more mental capacity on the actual tasks. Clear personal pipelines By 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. Non-intrusive progress tracking 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: : no action needed, 0 : < ½ hour, 1 : < 1 ½ hours, 2 : < ½ day, 3 : < 1 day, 5 : < 3 days, 8 : < 1 week 13 : < 2 weeks 20 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 bug, preventing core behaviour : live bug, not preventing core behaviour : needed for next release : needed the following release : nice to have Live 0 Live 1 Dev 1 Dev 2 Dev 3 Leader(s) / Delegator(s) 👨‍✈️ Leaders / Delegators are incredibly useful for: This allows developers to focus on their current task and not get distracted by the constant inflow of requests. Handling development requests and bug reports By helping developers pick the next task based on a number instead of it’s relevance to the business’s needs their deliverable increases. Prioritizing Tasks productivity **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. example: when moving a task from done to QA a comment should be left explaining what should be tested. Expected comments on task state changes 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 from at , expected actions specific people 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 , , , and more recently, . Thank you, , Kent, , and for putting up with me and for all your wisdom. Beamery Altar.io Innowave NearSt Michael Daniel André Adam

Slack

Twitter

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Code Project Management Quick but Huge Wins

Too Long; Didn't Read

Companies Mentioned

Pedro Esperança

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Code Project Management Quick but Huge Wins

Too Long; Didn't Read

Companies Mentioned

Pedro Esperança

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES