Github vs Basecamp board: What goes where?

1

Hi Ryan!

I’ll try to go straight to the point with an example.

Context
We use both Github and BC at my company. We’ve adopted the pitch strategy where we work out an idea in private and when it’s ready we share it with the company. (17 people including founders, devs, designers, operations and sales).

The issue
I have a proposal for the dev team and it’s very techincal. Where does it go?

Lets say I want the team to spend some time working on our background jobs system.
The idea is: I want to prioritize certain jobs related to payments to prevent important jobs from getting stuck in a queue for a long time.

I found myself writing a github issue to outline what I wanted to accomplish and how to go about getting there. Then I thought this seemed more like a proposal (or pitch?) than an issue… Nevertheless, all the language is very technical. So where should that live? I’m not sure every issue in a webapp is a proposal… but they aren’t all bugs either.

Thanks for an awesome book and taking time with these questions!
Felipe.

1 Like
2

Hey @gafemoyano - we worked through a similar challenge on our team recently and landed on the following principles:

  • Issues, feature-requests, and bugs get posted to Gihthub. These tickets just outline problems or ask for solutions that don’t require shaping. There can’t be any uphill questions left unanswered and the appetite for execution is measured in hours or days, not weeks.
  • Just about anything else would be considered a pitch and goes to the betting table.

If that doesn’t answer your question, I’d be happy to provide more color.

1 Like
3

Hi @mattdonovan, thanks for your answer.

That seems clear enough to me. In your personal experience, how would you handle kicking off the “tasks” assigned via issues en github vs cycle work? So far, I’m aware of two approaches:

  • Have a dedicated person doing support work during the cycle
  • Tackle it on cooldown

Thanks again for your answers!

1 Like
4

Great question - there is another thread on just that. Here’s my answer:

5

Hi Felipe

We also ran into a similar situation and, when the technical improvements take days, a pitch is also created. The pitch helps set the scope and appetite.

In our case, we have to have the CTO in the meeting so that the importance of the issue can be raised.

Business benefits (internal o customer-faced) can be explained in the pitch and that can confirm the value of the proposal.

This way, we can also make sure that we are not creating a pitch for just a new and hyped tech, like a new JS library or something fancy like that. We make sure to see the real business value.

In you case, sounds like internal efficiency, which is totally valid.

1 Like
6

I highly-disagree with this approach:

Shape Up explicitly addresses the problem in the chapter: “What about bugs?” I suggest you re-read it now:
https://basecamp.com/shapeup/2.2-chapter-08#what-about-bugs

It sounds like you’re giving issues and bugs a license to bypass the normal scheduled work cycle. This is anathema to the whole spirit of Shape Up. It threatens to preempt your planning, cause confusion about priorities, and stress your team.

“There is nothing special about bugs that makes them automatically more important than everything else.”

Work on bugs during the cool down, send them to the betting table, or perhaps dedicate an occasional bug smash cycle of appropriate length.

What I’d suggest is to run Shape Up as you normally would in Basecamp (we prefer doing Shape Up in Monday), then simply allow your team to use Github to get the work done. In this way, Shape Up is how you define and decide what to work on and to discuss any concerns that come up, and Github is used to managed how the work gets done–the implementation details in terms of branches, commits and pull requests. We continue any discussion of the task in Monday (Basecamp for most of you). Github is just used to organize how features (as branches) and for versioning (commits/pull-requests). Sometimes the engineers discuss technical implementation details in Github, but discussion about the scope of the feature or business-rules happens outside of Github.

here’s some tasks in a teams current cycle in Monday, along with some discussion of a rabbithole that came up in the sidebar

image
image1774×1764 438 KB

1 Like
7

These tasks get split up into multiple branches in Github–which business stakeholders don’t care so much about–and the conversion there is likewise technical (implementation details).

image
image1488×1400 225 KB

8

@maxhodges RE:

It sounds like you’re giving issues and bugs a license to bypass the normal scheduled work cycle. This is anathema to the whole spirit of Shape Up. It threatens to preempt your planning, cause confusion about priorities, and stress your team.

I suppose I could have called out explicitly that, while our team generally agrees with the spirit of Shape Up’s approach to bugs, we don’t feel great about any of the tactics. From my perspective, our team thinks bugs are different from other kinds of work in a few ways that make them worth triaging and prioritizing independently.

  1. A bug isn’t pitched, it’s reported. That means someone experienced it and it was bad enough for them to realize it. Bugs are embarrassing and, at least for now, our team is sensitive to that.
  2. Bugs often have few uphill questions. User-story-wise, we know what done looks like. We also have institutional knowledge about the development of that feature. Unlike shaping, the intended product is almost 100% prescriptive, which also makes them easier to size-up.
  3. Some bugs are leaches on previous bets. In Shape Up terms, if I make a bet on a pitch and the team produces something great that works, I’m making an assumption that it’s going to keep working. In that sense, I actually really like having ongoing bug fixes.

I should note that when any of our developers are working on bugs, they have had a hand in triaging them and deciding if what they’re looking at is worth working on right now or not.

I know there is some baked-in “stay busy” bias there, but our thought is as long as the engineer feels his or her time is well spent and they improve our product, what’s the harm?

1 Like
9

Our team here is very much in agreement with the Shape Up stance on the matter of bugs.

There is nothing special about bugs that makes them automatically more important than everything else. The mere fact that something is a bug does not give us an excuse to interrupt ourselves or other people. All software has bugs. The question is: how severe are they? If we’re in a real crisis—data is being lost, the app is grinding to a halt, or a huge swath of customers are seeing the wrong thing—then we’ll drop everything to fix it. But crises are rare . The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed. If we tried to eliminate every bug, we’d never be done. You can’t ship anything new if you have to fix the whole world first.

Ultimately software engineering is about adding-value. Sometimes fixing a bug is the most valuable thing you could be doing. Often times it’s not at all. The resources dedicated to a bug fix should be weighed against all the other value-adding activities you could be doing.

You’ve already shortlisted your best value-adding raw ideas, you’ve shaped them up, brought them to the betting table, and the team voted to bring them to the next cycle. Now you’re going to pre-empt all that evaluating, prioritizing, and planning because someone noticed your software isn’t perfect?

Frequently it makes little sense to interrupt the team’s momentum toward their current tasks just because someone found a bug. Surely whatever the team is working on must be something deemed to add a lot of value otherwise it wouldn’t have gotten past the betting table. A new feature might add value to a great number of customers while the bug might only affect a handful of users and in only a small number of circumstances. These things really need to be considered in the context of their impact and all the other value-added things you could be working on. Otherwise, you might win the Battle of the Bugs but lose the war for profits and market share and cede your competition an opportunity to win the hearts and minds of your customers. Your “bug-free” software can’t keep up with the velocity in which my team is able to add game-changing features.

The embarrassment you speak of is something we explicitly embrace. I’d rather apologize to a minority of inconvenienced customers than lose valuable momentum on a high-impact feature that’s going to wow masses of users, significantly improve operational efficiency, accelerate our growth, and have a big positive impact on our bottom-line.

That being said, we do care about bugs and we have processes to deal with them, we just feel their priority should be determined by a rational evaluation that puts them in context with other value-adding activities.

Think in terms of grading bugs along a “Bug Bell-Curve.” A small percentage of bugs demand immediate attention, a small percentage can be ignored for years, and most fall somewhere in-between.

Cheers! :ant: :spider: :mosquito:

4 Likes
10

Few questions on bypassing, e.g., Jira, and connecting Basecamp directly to GitHub:

  1. How can we track dependencies between tasks in each scope?

  2. How can we reference tasks to GitHub repo and do bi-directional linking?

  3. How can we track tickets in testing environments?

  4. How can we create release notes?

11

Our stance is that the only things that belong in GitHub are the code, pull requests, and code reviews, with minor exceptions such as getting started guides and quick tips in a README.

12

Any value in connecting to Basecamp though, for tracking and compliance reasons?

13

I don’t personally think so, trying to map to-dos from Basecamp into GitHub will just create confusion about what should be recorded as a to-do, the source of truth of a to-do, etc.

Also we explicitly close out Basecamp projects every cycle along with all of their to-dos completed or not because we don’t want lists lingering around distracting the core team from their priorities.

14

My team is thinking about using Basecamp to track at the feature level (scopes) and keep tasks in Jira (which is linked to GitHub). Thoughts?

15

What’s the problem you’re trying to solve? What justifies having to-dos spread over three websites?

16
  1. How can we reference tasks to GitHub repo and do bi-directional linking?
  2. How can we track tickets in testing environments?
17

I think if your team are already using Basecamp then just keep everything in there - let teams organise their tasks in there within each project. Then just use the GitHub for hosting code and pull requests.

I believe that is how the Basecamp team themselves use GitHub from what I’ve seen posted from Ryan, David and Jason.

Our team aren’t using Basecamp at all so we do everything within GitHub. For each project we’ll create one GitHub issue and then link off to smaller issues using a checklist within the body of the main issue.

The linking between pull requests and the issues are “nice” - but I’m not sure anyone would miss it. We don’t find any compliance or tracking benefits from it. We generally make sure to write up the details in the pull request message anyway.

18

Agree - an important aspect of Shape Up is autonomy. Basecamp offers the Hill Chart to show progress on a project over time, and Shape Up leaves tasks and task management up to individual team members.

@mhl66 you’ll want to find the right separation so that task organization and management is a benefit to each team member and habit forming, not an obligation.

1 Like
19

Thanks, @JoshAntBrown and @justin

20

DHH posted a tweet with a link to a livestream him and Jason did about how they use GitHub and Basecamp - thought worth linking here since it reminded me of this conversation.

2 Likes