Collab Hour
The Complete Guide
Download
This guide is evolving, so history is kept of the updates made over time.
Notable changes in v2
- The "Review" stage has been removed entirely, because pull requests are not necessarily a consideration at all in modern teams, and as such are not worth baking into the process. With the heavy emphasis on collaboration, peer reviews should happen naturally without a formal step.
- "Unblock" is now at the top, because knocking down walls is always the most valuable thing you can do for a team.
- "Retrospect" now comes before "Mob," because mob sessions tend to take all the remaining time, and retrospection is too valuable to skip.
- "Refine" is now last, because if a team has no tasks to work on, then refinement becomes the fallback activity anyway. All other steps are more valuable than planning, relatively speaking.
- Instead of low/medium/high, bugs are now classified as blocking, non-blocking, or partially-blocking. This language is less likely to be misinterpreted, and eliminates the need for follow-up explanations.
Summary
The model is straightforward: there's one daily working session called “Collab Hour,” for approximately one hour, where the entire process unfolds. This process forbids additional meetings without a clear justification. See the section on “when meetings are acceptable” for more details.
Regarding metrics, only those that reflect outcomes may be shared beyond the team. If any raw throughput data is collected, it must remain strictly internal. Since metrics typically influence management decisions, it's crucial they reflect the full picture fairly and accurately. Results tell a much richer story than pure speed or volume. Read more in the section on “Metrics.”
Seems Prescriptive... Is It Really Agile?
It's a fair question. Agility is about adaptability and collaboration, not process rigidity. This framework is designed to be just structured enough to protect and preserve the core values of the Agile Manifesto.
Teams are still encouraged to evolve the process continuously based on retrospective feedback. What matters is that the changes come from within the team itself, not imposed from above. The team owns the process, and that ownership is what keeps it agile.
Iteration is essential, but only after the process has been lived long enough to reveal its strengths and weaknesses, not as a reflex to old habits. It may take a few weeks to adjust, but the value of each guideline will quickly become apparent.
Collab Hour: The Daily Session
Each session, five descending priorities guide the agenda, though it's not necessary for all five to be completed before concluding the meeting.
- Unblock: Identify blockers to progress and resolve them during this session. If the team is capable of assisting immediately, then do not defer the task until after the meeting.
- Retrospect: Items should be added to a retro board in real time as ideas or problems come up. When the daily Collab Hour begins, the team should review any items and adjust accordingly.
- Mob: Identify the top priority and use mob programming to get it done. This involves the entire team including Product and QA; immediate feedback is invaluable.
- Claim: Before concluding, each team member should claim some work from the top of the priority list. Claiming work does not remove it from the next Collab Hour agenda; it only avoids conflicts. Half-finished, uncommitted work may be picked up by the entire group during the next session. Pair programming is encouraged outside of Collab Hour.
- Refine: Refine new stories, triage bugs, and prioritize tech debt.
Customers should regularly join the “Collab Hour” session to provide input and answers in real time. This may work fairly well at two weeks, which is a familiar cadence for many teams today, but the team should agree on whatever makes the most sense for them. It should be noted, however, that this does not require a release at the same interval. Favor continuous delivery; release at least once every day if possible.
The Details
When meetings are acceptable
Always favor “working sessions” over “meetings.” When determining whether scheduled time is necessary, it's required to answer “yes” to at least one of these two questions:
- Will this session accomplish a tangible outcome?
- Will avoiding this discussion impose a blocker to progress?
Additionally, we should also answer “yes” to this one follow-up question.
- Is this equally true for every single person in attendance?
If the answer to either of the first questions is “no,” then the meeting should not be planned. If the answer to the follow-up question is “no,” then all participants who are not required should be excused. These guidelines should be observed with strict discipline to avoid unnecessary interruptions.
If a meeting is necessary and it involves the entire team, the following day's Collab Hour session should be considered before scheduling a standalone meeting. If the topic can be addressed during the Collab Hour session, then it should be. If the topic is too urgent to wait, or it only concerns a couple members of the team, then additional time may be scheduled, but it should be kept as focused as possible.
All meetings should have a clear agenda. If the agenda does not align with the questions above, then the invited participants will be expected to decline the meeting. The facilitator should be held accountable for scheduling only necessary meetings. Productive work should always be the priority.
With that in mind, collaborative sessions are encouraged, such as pair or mob programming. With empathy, take into consideration your coworkers' social tolerance levels before allocating extra time. For some, Collab Hour alone may be pushing the limit. The important part is optimizing team synergy, for the most enjoyable and productive collaboration experience.
Unblock
If any team member is blocked, whether by something outside their control or simply by a difficult task that requires assistance, then the team should swarm on it to resolve the issue promptly.
If the organization and team are structured properly, then no blocker should lie beyond the team's power to rectify internally. If key people are unavailable to make a decision or answer a question, a tentative decision may be made without them; it's better to make the wrong choice and revert later than to pause forward progress.
Retrospect
A key part of Agile is continuous improvement, often achieved through retrospectives ("retros"). Sticky notes (or digital equivalents) are typically used to categorize ideas into columns like "start, stop, continue."
Collab Hour isn't meant to stay frozen in its first form — it should evolve as the team learns and grows. Every team must have full autonomy to adapt the process to its own context and challenges.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
— Agile Manifesto
Ordinarily, teams schedule a bi-weekly meeting to stop and have an open discussion about the process. However, interrupting work to force a discussion can be disruptive.
An alternative approach is to continuously reflect throughout the day. The retro board should remain accessible at all times so ideas can be recorded as they arise. During each Collab Hour, the team can address each suggestion.
Mob
Mob programming is a tactic for group collaboration on a single computer. With remote work becoming more commonplace, this can be accomplished by using tools such as VSCode's Live Share extension, or IntelliJ's Code With Me. You can try different approaches and adapt it to what works best for the team, but essentially, mob programming is the idea of rotating the following roles at regular intervals, such as every ten minutes.
- Driver: The typist, responsible for implementing instructions provided by the navigator. This role offers valuable learning opportunities.
- Navigator: Coordinates input from team members and guides the driver. This role is ideal for leading the team.
- Advisors: Everyone else in the room is tasked with open communication, answering questions, and making suggestions. This role is best for offering a specific set of knowledge or expertise.
While these roles provide structure, teams should feel free to adjust them as needed. A mature team may even spontaneously switch roles based on emerging ideas or needs.
During the Collab Hour session, the team should identify the highest priority task and use mob programming to complete it together. If the clock runs out before the task is done, finish the current thought and then commit the code before ending the session. Engineers may choose to continue working on the task after the session ends, but after Collab Hour, the team is free to drop off as needed.
If there is no urgent task to address, then the team should move on to the next priority. Remember not to neglect the retrospect portion for too many days in a row.
Claim
All team members should leave Collab Hour with a clear understanding of who is working on what, to avoid conflicts.
Tasks should be prioritized from top to bottom, and should be claimed from the top of the list. Cherry-picking from the middle or bottom of the list is generally discouraged; the agreed priority list should be respected to ensure the team is always delivering the highest value.
Refine
Refinement (sometimes known as grooming) is the process of preparing and understanding the necessary development tasks.
This time should focus on clarity and prioritization, but not estimation. The authors of the Agile manifesto generally agree that estimates are counterproductive, in either time or story points. The cost of time and value wasted outweighs any value gained; decades of peer-reviewed research confirm that estimates are unreliable and observably harmful to decision making and behavior.
Stories
User stories are the most common type of task in software. They are intended to orient the team around the user's needs, rather than the technical implementation.
Instead of making judgment calls about whether a story is "small enough," it's better to always reduce every story to the smallest it can possibly be. That said, stories should not be split on the wrong axis, like dividing front and back end work for example. A story should be framed as a user's expectation, which usually involves a complete vertical slice of the system, from the user interface to the database. For further guidance, see Ron Jeffries' approach to crafting good user stories.
When it comes to large collections of stories, Jeff Patton's "story mapping" technique is a great way to visualize the user journey and prioritize stories based on user needs.
Bug Reports
Careful bug reporting can avoid unnecessary confusion and delays in fixes. Below is a checklist of items that should be included in every bug report.
- Environments: Not only the environment the bug was reported in, but all environments where the bug exists. (e.g., QA, STAGING, etc.) This is crucial to narrow down the root cause.
- Steps to reproduce: A comprehensive list of all user actions from the moment the app is opened until the bug is observed. Leaving gaps to interpretation may hinder a prompt fix.
- Scenario: It's the responsibility of the reporter to ensure that the bug can be reproduced in a context that's useful to the developer(s) fixing the problem.
- Expected vs Actual: Clearly articulate the correct behavior versus what is observed. This reduces uncertainty and provides guidelines for acceptance to close the bug.
To triage bugs effectively, determine the severity in terms of "blocking," "non-blocking," or "partially-blocking." A bug is blocking if it prevents the user from completing a task.
The severity of a bug is not necessarily related to its complexity. A "blocking" bug may be a simple fix, while a "non-blocking" bug may be difficult to resolve.
Avoid creating bug reports for features that haven't yet been released. Instead, return the task in question to the developer, as additional tracking will only create confusion.
Technical Debt
Technical debt, or just "tech debt," is the cost of delaying long term stable solutions to deliver something faster. Tech debt is not inherently bad, but it should be limited to avoid slowing progress.
Only those intimately familiar with the code architecture and the impact of changes can accurately assess tech debt. Thus, it's exclusively the engineers' responsibility to identify and prioritize tech debt items, especially when intentionally incurred for expediency. Those who lack the appropriate technical context should not make the final call in these decisions.
Engineers must be allowed sufficient time each day to pay down tech debt, or else risk issues with stability and significant declines in delivery speed.
Customer Feedback
Feedback is a critical component of any successful team. It is important to regularly solicit feedback from customers to ensure that the team is building the right product, constantly adapting to change rather than focusing too much on scope and requirements up front.
“Responding to change over following a plan”
— Agile Manifesto
Customers should be invited to join the Collab Hour session to create an open dialogue, so that the team can better understand the needs and expectations of the end users. The frequency of customer feedback sessions should be determined by the team, but the standard is every two weeks.
These feedback sessions do not require a release at the same interval. It's often best to release features as soon as they are ready, rather than waiting for a predetermined release date.
While not specifically required, a continuous deployment strategy works well with this model. Feature flags allow the team to release features to production without making them visible to end users. This minimizes the risk of long-lived feature branches and allows the team to gather feedback early and often.
Metrics
Teams are not required to track metrics, but they may choose to do so. All throughput metrics must be kept strictly confidential, for the team's eyes only, apart from HR, upper management, executives, stakeholders, and so on.
Metrics focused on outcomes, such as those listed in the DORA Metrics, may prove more valuable to external parties than velocity, for example.
“Working software is the primary measure of progress.”
— Agile Manifesto
Performance tracking places unnecessary stress on the team, which can lead to a decrease in morale and thus increase turnover. Furthermore, surveillance of such metrics often drives the wrong behavior, such as inflating numbers and rearranging tasks to make the burndown chart look better, rather than focusing on code quality, customer value, or business revenue.
While performance metrics may seem easy to measure, ignoring nuance in the circumstances may lead to incorrect conclusions. For example, a senior engineer may go several weeks without delivering a single story, but they may be providing invaluable mentorship to the team. The value of this mentorship is not reflected in the metrics, so when evaluating performance, it may wrongly appear that the engineer is not contributing.
The full and accurate truth is not easily quantifiable. This is a fact of life. To make the best decisions, we must accept this uncomfortable reality and remain cognizant of the limitations of our data. Instead of predictablitiy, we should optimize for effectiveness, which inherently involves a degree of uncertainty. The alternative is to optimize for metrics, which is a dangerous path that often leads to poor outcomes. Read more about estimation and story points in the Refine section.