Improving productivity between teams in software development

Photo by Lala Azizli on Unsplash

This is Part-3 of “How paypal engineers turned buggy software into great stable software”, You no need to visit previous parts to understand improving productivity b/w teams.

If you want to checkout the whole journey cycle then you can checkout other parts.

Once again 😎, This article will be more focus on improving the productivity of engineering teams.

(It will be beneficial who want to manage their tech people better)

PR reviews

• Every developer in a team has lot of PRs to get review from senior folks, these seniors used to have they busy meeting with PMs and other stackholders
• To get the review faster, they implemented PR slots on hierarchy basis
• Lead Engineers has setup the PR slots to review SDE III eng. devs PRs, SDE III engineers has slots to review SDE II PRs, and so on…
• So accordingly these developers used to prepare all these PRs and used to ping their respective senior folks to get it done PRs✅

DEV QA (optional)

• Before raising PR’s, each dev should do testing and list down all possible test cases
• It will become easy for QA engineers to review all test cases and extend other possible test cases.

Retrospection

• These Retrospection meetings will conducted on each end of the sprints, where they will discussing on “where things get blocked and slow down the development process”
• For example — UI/UX designers sent another iteration UI after development team started picking that UI, another example where QA testing team is picking the development tasks slower.
• These type of issues used to discuss and note it down and send it to higher management to get rid of all these issues in next sprint.

Appreciation & team lunches

• Most of the companies neglect about it, In general these Appreciation certificates or gifts will motivates people to extended their abilities to make them feel important.
• Team lunches will give good coordination between all the people in a team (My senior folks used to order expensive drinks🥂 and enjoy:-)

Dependencies

• If higher management used to see if any devs used to struggle in project. they used to involve other devs and used to assign same tasks which you getting assigned. so that these devs can collaborate to learn better.
• If these devs are not showing interest and not contributing properly. Then they will be get suspended as part of low performance.

No Meetings

• We used to have no standup meetings one day per week and other unnecessary meetings kind of day looks like meeting free day to increase their productivity.

Jira board

• All devs and co devs can see the board which tasks is get assigned, (I used to see other devs what tasks are they get assigned and used to know more about their tasks to check whether they are doing something cool)

Release branches

• There are only two branches, one is dev and another is release
• Initially developers need to create their new branch from dev branch if they are getting more tasks they can create more branches from feature branch or dev branch according to their needs
• Once tasks are tested by QA and ready to go release (prod) then they can merge their feature branches to dev branch and get it again tested from QA at a same day or two should move to release.

If your task is not going for release due to task under prioritised from product manager or project manager then that branch shouldn’t push to even dev branch.

• We faced some senarios where these devs used to merge their code to dev branch without knowing when it will go to prod. At that time we see lot of unneccasry code was been their in dev branch and it will be very difficult to push some other particular piece of code from dev to release.
• Also these individual branches will be cleaned up every 3 months so that these branches won’t get mess up with another branch names

Assigning time allocation for each tasks

• We used to have one discussion call before starting the sprint where lead and other senior folks explain all tasks
• At the end — all team members in meeting to estimate the time of all tasks. so that everyone aligned complexity of all tasks, according to it manager or lead will assign the tasks.
• When estimation of tasks, there will be some tradeoffs some devs can estimate 10hours and some other can estimate 5hours then these senior folks will asks these two groups why it will take 10hours or why it will take 5hours. According to explination then it will increase/decrease the time estimation of the tasks.
• It helps in cutoff lot of assumptions and can clarify more info about these tasks b/w team members. so that team will be clear cut idea what to contribute and prepare themseleves to contribute better.

Not the least

• Every module of code written with unit tests and some function tests with playwright or cypress, if existing development cycle not have time then they reprioritized in next sprint cycle.
• Some times they used to assigned small team of devs to write unit tests and functional e2e tests (as a prioirty) to all modules and then other existing devs in team can modify those unit tests later.

Hope you enjoyed it feel free to ask questions.