There are two dangers in most project tracking tools. One is the one discussed here: the assumption of one project, one person. The second is the assumption that it is “OK” to have one person assigned to 2, 3, 4, 5, … N projects that are currently in-progress.
My rule to fix this is that a product/engineering team’s entire iteration/sprint/whatever project plan should fit on a single 720p screen. You should be able to see todo & in-progress in that single screen. You should be able to see pairs and triplets of assignments on the same screen. Trello or Notion or GitHub Project Boards can accomplish this. Many tools cannot.
Ideally, one person is only on one project, and, as suggested here, that person is joined by colleagues of diverse skillsets/experiences, forming a development “pod” of 2-4 builders per project.
Occasionally, one person is spread onto two projects, but one is “primary focus”, and the other is “as an advisor/reviewer only”. That can work, with care. If one person is on two projects, they are likely “strained”, though. If they are on three or more projects, they are definitely spread thinly and the team should rebalance or de-prioritize projects. If your project board fits on a 720p display, your brain will spot this quickly. Focus is key, as this post suggests.
I wrote about this more in “Software planning for skeptics”:
Occasionally, one person is spread onto two projects, but one is “primary focus”, and the other is “as an advisor/reviewer only”. That can work, with care.
Yes, it seems to me that such an arrangement where one person can be both a “primary” on one task, and “secondary” on another one, is an acceptable compromise, especially if for cultural reasons people are reluctant to buy into an idea of “wasting time by assigning people redundantly to one task”. At very least there is some explicit redundancy and expectation of staying in the context of each project.
I wrote about this more in “Software planning for skeptics”:
Few months ago we’ve added an additional label to our tickets called “Ticket companion”, the ticket companion is not fully responsible for finishing the ticket but is meant to support you in whatever means necessary. This way we occasionally end up working on one ticket together, which is especially helpful with beginner engineers.
Unless we are talking about pair-programming, two people are not going to work on the same thing, just two very related things, so you can create two related but separated subtasks for only one person each.
Sure they will. They will talk, design, review, pair program, have some meetings when one person will be busy and come back to sync a little later and so on. They are going to have fun, learn from each other and do better job faster than a lone person would.
This is very good! But consider grouping beyond just multiple software engineers: Pull requests are not the only queue that adds risk due to information loss. Software development process is often a longer and lossier game of telephone. Bring your testers along and do the total task together. Find ways to share work with designers too, so they can see their vision through and you have earlier chances to negotiate what’s feasible. Ideally, collect everyone you need to start and finish the unit of work. The benefits listed at the end of this article can extend not just between programming staff but among all production staff, and can elevate their perspectives out of individual disciplines and to the level of the product. YMMV; you can’t remove every queue, but think about where it might work.
But consider grouping beyond just multiple software engineers
I agree in principle, though it’s all entirely dependent on larger picture organization. Some teams have a strict separation between UX/UI and backend and it works OK for them, some not so much. Some have designated testing teams, so depend on developers doing the testing. Some teams are devops heavy, some are mostly about application itself. All I know is that one lone person delegated to do something is rarely optimal. How many, how exactly and what type to involve is something that each team needs to figure out for themselves. It obviously is possible go to overboard in the other direction, and have many people wasting time with nothing to do. 2 people seem to me like a good default.
The right balance absolutely depends on the org. You could not overdo it completely and sustain that.
Teammates are good at optimizing by hill climbing, but they will rarely leave the hill you started them on. They won’t insert themselves in someone else’s space, especially across disciplines, but they will take their leave of a group when they feel it’s not time well spent. Siloing by default leaves on the table the benefits you’d get when they would choose to stay in the group but wouldn’t have chosen to interrupt someone.
So I do think a team should start by overdoing it, see where they then think the best balance might be, and then dial back toward it. I think companies are underdoing it, most have always underdone it, and the right balance for each is unknown. Getting to the best balance in fewer iterations is useful, and you have lots of data left of the optimal point, so try to get a reading surely beyond it. Experiments can get more fine grained once you have an upper bound.
There are two dangers in most project tracking tools. One is the one discussed here: the assumption of one project, one person. The second is the assumption that it is “OK” to have one person assigned to 2, 3, 4, 5, … N projects that are currently in-progress.
My rule to fix this is that a product/engineering team’s entire iteration/sprint/whatever project plan should fit on a single 720p screen. You should be able to see todo & in-progress in that single screen. You should be able to see pairs and triplets of assignments on the same screen. Trello or Notion or GitHub Project Boards can accomplish this. Many tools cannot.
Ideally, one person is only on one project, and, as suggested here, that person is joined by colleagues of diverse skillsets/experiences, forming a development “pod” of 2-4 builders per project.
Occasionally, one person is spread onto two projects, but one is “primary focus”, and the other is “as an advisor/reviewer only”. That can work, with care. If one person is on two projects, they are likely “strained”, though. If they are on three or more projects, they are definitely spread thinly and the team should rebalance or de-prioritize projects. If your project board fits on a 720p display, your brain will spot this quickly. Focus is key, as this post suggests.
I wrote about this more in “Software planning for skeptics”:
https://amontalenti.com/2017/10/27/skeptics
Yes, it seems to me that such an arrangement where one person can be both a “primary” on one task, and “secondary” on another one, is an acceptable compromise, especially if for cultural reasons people are reluctant to buy into an idea of “wasting time by assigning people redundantly to one task”. At very least there is some explicit redundancy and expectation of staying in the context of each project.
Good read! I agree a lot with most if not everything in there!
Few months ago we’ve added an additional label to our tickets called “Ticket companion”, the ticket companion is not fully responsible for finishing the ticket but is meant to support you in whatever means necessary. This way we occasionally end up working on one ticket together, which is especially helpful with beginner engineers.
I like it! (as a workaround)
That’s what an “Epic” is for.
No, I can’t agree. Epics are much larger bodies of work. What I’m saying is down to individual task, it’s better to go in pairs.
Unless we are talking about pair-programming, two people are not going to work on the same thing, just two very related things, so you can create two related but separated subtasks for only one person each.
At work we create a lot of those (micro) epics
Sure they will. They will talk, design, review, pair program, have some meetings when one person will be busy and come back to sync a little later and so on. They are going to have fun, learn from each other and do better job faster than a lone person would.
Or at least that’s the plan.
Do you mean “epoch”?
Jira speak for multiple stories on a single task
This is very good! But consider grouping beyond just multiple software engineers: Pull requests are not the only queue that adds risk due to information loss. Software development process is often a longer and lossier game of telephone. Bring your testers along and do the total task together. Find ways to share work with designers too, so they can see their vision through and you have earlier chances to negotiate what’s feasible. Ideally, collect everyone you need to start and finish the unit of work. The benefits listed at the end of this article can extend not just between programming staff but among all production staff, and can elevate their perspectives out of individual disciplines and to the level of the product. YMMV; you can’t remove every queue, but think about where it might work.
I agree in principle, though it’s all entirely dependent on larger picture organization. Some teams have a strict separation between UX/UI and backend and it works OK for them, some not so much. Some have designated testing teams, so depend on developers doing the testing. Some teams are devops heavy, some are mostly about application itself. All I know is that one lone person delegated to do something is rarely optimal. How many, how exactly and what type to involve is something that each team needs to figure out for themselves. It obviously is possible go to overboard in the other direction, and have many people wasting time with nothing to do. 2 people seem to me like a good default.
The right balance absolutely depends on the org. You could not overdo it completely and sustain that.
Teammates are good at optimizing by hill climbing, but they will rarely leave the hill you started them on. They won’t insert themselves in someone else’s space, especially across disciplines, but they will take their leave of a group when they feel it’s not time well spent. Siloing by default leaves on the table the benefits you’d get when they would choose to stay in the group but wouldn’t have chosen to interrupt someone.
So I do think a team should start by overdoing it, see where they then think the best balance might be, and then dial back toward it. I think companies are underdoing it, most have always underdone it, and the right balance for each is unknown. Getting to the best balance in fewer iterations is useful, and you have lots of data left of the optimal point, so try to get a reading surely beyond it. Experiments can get more fine grained once you have an upper bound.
Feels like a concise summary of On Pair Programming. 👌🏾