The key is to identify the different needs: code repository, task management, issue ticketing/tracking.
1 Reply
- 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.
2 Reply
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 5
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.
3 Reply
- 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.
- 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.
- 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.
More here
Github better than BaseCamp