Jack Wellborn

Someone recently asked me to collect some of my thoughts on process and agile. Below is said collection of these thoughts. They are based on my own limited experience, and may be added to or amended over time.

Process

• “People over process.” Process should be defined and refined in collaboration with those subjected to it.
• Process should make work easier in the long run. A process that remains burdensome needs to change or stop.
• A major way process makes things easier is by sensibly answering the repetitive question “so what happens next?”
• Process is also a contract between stakeholders. For example, an incident that affects only one small customer can’t be a P1 if everyone has agreed that P1s require several large customers.
• As with any contract, process necessarily requires trust and accountability. Process without either is just theater.
• The lighter and more rote the process is, the more likely it will be adhered to.
• While bad tools do exist, complaints about tools more often than not stem from issues with the process.

Project Management

• Project management is really the work necessary to effectively communicate the answers to four questions:
  1. What is the work and
  2. Why does it matter?
  3. How will the work be completed?
  4. When will the work be completed
• You can’t answer the “how” without first answering the “what” and the “why”.
• Similarly, you can’t answer the “when” without first answering the “how”.
• The answers will change over time.
• Project management tools are communication tools whose primary purpose is to progressively disclose the most current answers to these questions.
• The data used for project management must become the single source of truth. Multiple datasets begets multiple competing answers.
• Project management fails when the answers can no longer be trusted.

Daily Stand Ups

• Stand ups should typically be in person (colocated or via remote meetings) with some exceptions.
• Each team member should answer three questions:
  • “What did I do yesterday?”
  • “What am I doing today?”
  • “What are my blockers?”
• While additional time can be set aside for parking lot, the stand up portion should typically take about 15 minutes.
• Parking lots are optional. When they do happen, only those needed for a given discussion should be required to participate.

Refining Tickets

• Accept that refining tickets is work and merits dedicated time and effort.
• Refining should be a collaborative effort involving the entire team. Leaving the responsibility to just the product owner is deeply unfair, and can lead to an antagonistic relationship between product and engineering.
• Most tickets should have user stories.
• Lean into templates. Templates provide a consistent language that reduce friction when writing or reading them.
  • For example, “As ____________, I would like ____________ so that ____________.”
• Anyone can write user stories, but user stories for features are typically owned by product.
• Similarly, everyone can add acceptance criteria, but acceptance criteria is typically owned by those responsible for the work.
• Avoid refining too far into the future because those efforts will go to waste when things inevitably change.
• Take caution when filling details with assumptions.
• More words does not necessarily mean more detail. Long meandering prose often results in confusion rather than direction.
• Additional context is welcome, but should be progressively disclosed, either after the user story and acceptance criteria and/or via a link.
• Use a definition of done to identify acceptance criteria common to most tickets. Acceptance criteria in the definition of done are presumed and don’t have to be explicitly added in individual tickets.

Estimating Tickets

• Accept that estimating is also hard and that estimations are almost always wrong. (That’s why they’re called “estimations”.)
• Estimations are not promises.
• Estimations primarily exist to provide data that can be used to forecast capacity.
• Estimate using an abstraction such as story points that represent effort or complexity rather than time. Time can be considered when determining effort or complexity, but estimating solely based on time leads to tears as presumed promises are repeatedly broken.
• Use time-boxing for open ended tickets, such as researching a given topic. While it sounds like time estimation, it’s more of a cap of how much effort the team is willing to invest on a given initiative.
• Use relative sizing. We may not know precisely how complex making a pizza from scratch is, but we do know it’s more complex than baking a frozen one.
• What constitutes a story point is determined by the team, and therefore may differ between teams. An issue with 5 story points on one team might be an 8 on another.

Managing the Backlog

• Accept that managing the backlog is also work and merits dedicated time and effort.
• The backlog should be ordered with the highest priority items on top. Team members should easily be able to see upcoming work.
• The backlog should be a to-do list. You should only be refining work you intend to do. Ideas are great, but should live elsewhere.
• Ruthlessly cull backlog items that become irrelevant or are no longer foreseeably going to be completed.

Planning

• Planning typically becomes rote when tickets are already well defined, and the backlog is well managed and prioritized.
• The goal is to complete all committed tickets by the end of the sprint.
• When the team is unsure if a ticket can be completed, it’s better to ask for permission instead of forgiveness. In other words, it’s better to pull in uncommitted tickets after committed work is complete than to commit to tickets you may not have time for.
• A good way to break a cycle of repeatedly carrying over tickets is to aggressively limit introducing new work until no tickets are carried over.
• Confidence votes can provide team members an opportunity to raise and mitigate concerns before committing.

Retros

• Retros are a space for team members to give feedback and implement change.
• Feedback should be prioritize based on the team’s ability to implement change.
  1. Stuff that the team has direct control over
  2. Stuff that the team can only influence
  3. Everything else
• Retros are a private discussion for team members only.
• Avoid getting personal. For example, instead of accusing a team member for being slow, point out that a given ticket seemed to take longer than expected.
• Feedback that can be addressed should be considered for action items.
• Action items are like promises. Only create them if the team is committed to fulfilling them.
• The work corresponding to action items should either be refined into tickets or deducted from capacity.

Capacity

• Capacity is best determined by historical velocity (the average story points completed in prior sprints.)
• Lacking historical velocity, make something up to start. For example, 8 story points for each full-time team member.
• When making up capacity, deduct a substantial (~30%) amount for unplanned work.
• Be sure to call out if and when team members are working extra hours (nights, weekends) as doing so inflates capacity and accelerates burnout.

Teams

• Teams larger than 10 should consider splitting into smaller teams.
• Team members should be dedicated to one team.
• While team members inevitably turnover, the goal should be to keep continuity so members can build rapport and subject matter expertise.
• Clearly define what features and projects the team is and isn’t responsible for.
• Also define how those features and projects fit with the wider organization. In particular, identify adjacent features and projects, as well as the teams who manage them.
• Define custody of shared projects to avoid a tragedy of the commons. Custody of a shared project can be assigned to a community of practice.

Communities of Practice

• As with teams, define what the community of practice is and isn’t responsible for.
• Recognize that those expected to participate in a community of practice will have less capacity available to their team.
• Work should not be done directly by the community of practices, rather it should be assigned to members’ teams.
• A community of practice that is managing projects directly is really just another team, but one filled with part-time loaners who already have a day job.