Jack Wellborn

Tom Brady retiring got me thinking about what it was like being a Patriots fan before the greatest quarterback of all time.

I grew up in a Patriots household. My dad moved around quite a bit while growing up, but his family settled just outside of Boston in 1960, the inaugural year of both the Boston Patriots and the AFL. I suspect for this reason my dad adopted the Patriots more than other Boston teams. His casual fandom was rewarded by decades of incompetence and heartbreak. This is hard to believe today, but the Patriots were nothing short of a joke. In the 30 years between their inception and 1990, the Patriots made the playoffs only five times. Two of those five seasons, they did miraculously make it to a championship, but only to be blown out by historic proportions both times.

Historic mediocrity was probably the main reason I didn’t watch football until I was about 12. Patriots games weren’t worth airing even in northern Connecticut, where I grew up. I have memories of watching my frustrated father attempting to adjust the rabbit ears so as to catch the broadcast out of Springfield, MA. It never worked. I started paying attention to my father’s team after the teams third owner, James Orthwein, hired Super Bowl winning coach Bill Parcells. Parcells then drafted top QB Drew Bledsoe. Finally, Robert Kraft bought the team after blocking Orthwein from moving them to St. Louis.

My young self figured perennially competitive NFL teams had at least three things.

1. An owner who is as competitive and passionate as they are business savvy.
2. A smart head coach, who can manage both the culture and the game.
3. A winning QB.

By 1994, the Patriots seemed to have all three. Kraft was competitive and passionate, Parcells was a truly great manager of players and the game, and Bledsoe turned out to be just as good as everyone thought he’d be. In 1996, they went to their second Super Bowl. They were blown out again, but at least not historically so. Honestly it wouldn’t have been so bad if not for a falling out between the coach and the owner, the likes of which I suspect only Cowboys and Chargers fans can relate to. Making matters worse, Parcells and his coaching staff left for our bitter rival, the New York Jets.

After four middling seasons under Pete Carroll, I lost interest. I had just started college and didn’t really have much time for football, but I did take notice when Kraft hired Bill Belichick away from the Jets. Not only did it add a juicy new chapter in the drama between the two teams, I had remembered Belichick specifically. I remembered that he was the coach in Cleveland that beat my Parcells led Patriots in the first round of the 1994 playoffs. I also remembered when he joined Parcells’s staff in New England in 1996, when the Patriots went to the Super Bowl. Parcells’s Patriots were always competitive, but this was the first time I remembered the team playing smart.

Then in 2001, after a mediocre 5-11 2000 season, something terrible happened. Drew Bledsoe, the Patriots all pro quarterback, was taken out by a vicious hit by Jet Mo Lewis. That hit was so violent that it sheered a blood vessel, causing the star severe internal bleeding. It’s important emphasize how Bledsoe wasn’t just some quarterback. To that point he was arguably the best player the Patriots ever had at the position. Just look at his accomplishments. Bledsoe was a great quarterback and no one really thought his back up would ultimately become the starter in that first game against the Jets. As that season continued however, all us Patriots fans watched the new guy play. He didn’t have Bledsoe’s arm or any other notable physical abilities, but there was something about him. The 6th round pick passed the ball to everyone. He made the offensive line look good. In the fourth quarter, he threw game winning touchdowns instead of soul crushing interceptions. One by one, us fans started to notice that regardless of whether or not the new guy was the better quarterback, he inarguably made the team better.

In a mere 9 weeks in 2001, Tom Brady proved himself to be the starting quarterback of the New England Patriots. He continued to prove himself in the decades since, first that he wasn’t a fluke, then that he was great, and finally that he was truly the greatest of all time.

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.