GitHub GitHub Universe 2020: Enterprise - DevOps, 10 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How GitHub uses GitHub to plan and track work - GitHub Universe 2020

Description

Presented by Lauren Brose, Senior Product Manager, GitHub

Hear directly from the Product Manager of Issues on how her team takes an idea to the cloud. You’ll get an overview of how labels, milestones, project boards, and references can bring this process to life on the GitHub platform, and learn some tips for how to make the most of tools.

For more from GitHub Universe 2020, visit https://githubuniverse.com

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub

Thanks!

Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

Hi everyone uh welcome to this talk about how github uses github to plan and track work. Now github is a really large company with almost 2 000 employees, and so it takes a lot to make sure we're all kind of growing in the same direction.

A

uh However, at the same time, we believe in empowering teams to work autonomously so that they can make decisions and iterate on product faster, and so you know with that autonomy, though we still have to be able to align as a company with wider planning, so I'll be focusing on two sides of that coin.

A

One is how do we actually set up our teams for success and empower them to be autonomous, and what do we do as an org to align so that we can make sure we're all sailing in the same direction uh I'll quickly just reintroduce myself? So my name is lauren bros, I'm a senior product manager at github, and I work with the teams making improvements to the issue space.

A

So when I talk about what teams do day-to-day I'll be drawing from my experience, working with the issues team, but the beauty of autonomous teams is that we can all approach the same planning and tracking challenges in different ways, and so I hope, by sharing my experience, you can kind of come out with a tip or some way to improve yourself as a team, and I'm super looking forward to talking about discussions, ways that maybe y'all work that we could improve as well.

A

So what we're going to cover I'll talk about the people? How do we actually organize ourselves to maximize autonomy of our engineering teams? Then I'll? Take you through? How do we think about taking an idea and turning it into an impactful code? Change that reaches all of our users- and you know throughout I'll, also be discussing. How do we use issue building blocks like our labels, milestones templates and our own team processes in a way that we think works really well and through this?

A

I hope you'll learn a little bit about how github thinks about its own planning tools and come away with something new that you can use on your team, and you know with that. I'm just going to jump right into how do we set up our people so at github we take our product development group. You know within our 2000 person organization and we split them into what we call epd squads so epd. It stands for engineering, product and design, and the idea is that this is really a cross-functional team.

A

That's working closely together on a specific problem, uh so they're they're, actually pretty small, there's generally one product manager, one designer one engineering manager and then like four to six developers, and we would like to keep them small because we believe that kind of creates focus like you can really only take on one problem at a time as a group, and so each squad is kind of pushing the same rock in one direction as opposed to a larger team.

A

You might be tempted to have like four or five rocks that you're trying to push at once, um and so that's that's really kind of how we've broken apart. Our engineering group, but I can't talk about our epd squads without talking about the repos, the places where they're actually making these code changes.

A

So it may or may not be surprising to you, but the code that powers github.com that you use every day is actually mostly in a mono repo. So all these epd squads across github are you know, opening pull requests committing deploying all from the same repo, which in itself is a little bit chaotic at times. So you can only imagine the chaos amplified if every single epd squad in our entire organization was also trying to open their issues track changes.

A

You know, create labels, change templates, nobody would be able to agree on anything and it would be impossible to follow any notifications so to mitigate that each epd squad actually has its own repository set up specifically for their issues and team docs. So I've got a picture here of the github issues. Repo you can see. We've got a bunch of issues open a couple: pull requests as we're changing our docs.

A

uh We have a readme where we talk about. How do we fit in the organization outline some of our goals for a quarter, uh and this really gives us a little bit of personality as a team, but we're also really empowered to just change whatever we need in this repo as we go through our day-to-day work, so everybody has admin permissions. They can open up settings, add a template at any time. You know decide. We should turn on actions, uh decide to turn on enough discussions.

A

All of that- and this is just a way- that we really let teams kind of be creative and keep keep their work and have a clear home.

A

But you know there is one exception to this, and that's bugs you can imagine if every team at github is trying to track bugs in each of their repos. Nobody would know where to file it. You know at github, since we use github to build github, you hit the occasional bug in your day-to-day work and you want to make sure that we fix it, and so we actually standardize on opening those bugs in the github github monorepo.

A

So that's the one type of issue you'll find there and that helps us facilitate conversations like you see in these comments, where people are trying to find the right team to really tackle the bug or have the context required to fix it, and but at the same time, as you can see, these, these comments are pinging an entire squad of people and that sets off this like race, like every person in the squad, wants to be helpful, wants to respond, and now all eight people in the epd squad are running to answer this question and all randomized, which is a really great way to work.

A

It's very distracting. So we've come up with this role within the epd squad. We call the first responder and the first responder kind of rotates each week. It's just one person in the engineering part of the epd that is responsible for replying to those bug.

A

Pings on the github, get monorepo they're, also responsible for reviewing any pull requests into our areas of maintainership that are coming from other teams, and you know, while they're first responder for the week, they're really just focused on fixing bugs and any other maintenance items that come up, and this helps protect the other focus from the rest of the team, so that you know they see an issue-wide team ping. They know. Okay, whoever's first responders got it. I can keep my head down and keep focusing on whatever I'm trying to tackle.

A

So that's kind of how we've organized ourselves. We've got our epd squads that have their own repo for work. They work in a monorepo where we also keep bugs to make it easy for anybody in the company to file, and then we use the first responder to make sure that we're having a high bar for quality, and that is a great segue into the actual issue life cycle.

A

How do we think about actual future improvements or product improvements that we're making and what does that flow look like? So I have this diagram here where I've kind of got two parts. I've got a planning phase or you know I might have an idea. I scope it to something manageable and then I prioritize it in my backlog of work and then I kind of shift to this tracking phase. Where now I'm just executed, I'm building things, I'm getting it ready to release to our users um through that execution cycle.

A

You know, I have something I need to learn. I build something I demon demo it to. You know: internal teams, customers. I just keep going on that loop until I'm ready to actually release as a beta or general availability, and then you know as soon as it's in the hands of users, you get that feedback. That starts the next idea and that's really the full cycle, and so what I'll do is I'll just go through each phase and talk a little bit about the tooling that we have?

A

That makes it happen, so it's just starting at the beginning. How do we actually capture ideas for how to improve our products?

A

Now I have this sticker on my laptop, it says all my issues are on github and I think that's the core of capturing ideas. You want to write it down in a place that you can easily share. So when you open an issue, you've got a url. You can send it to anybody for feedback.

A

The other great thing about capturing those ideas and issues is that it's indexed, it's searchable. So within the github organization. If you have an idea for something like adding video support to comments, uh you can just do a quick search and find any any historical context and as your organization grows it, you just have this wealth of knowledge and issues which is really great.

A

The the people that wrote it might be gone, but you've got that whole history right there in the issue. um But if everybody's opening a bunch of ideas and issues, how do you keep them organized? How do you make sure you have enough information that years from now, it's still actionable and that's where we've really heavily leveraged issue templates?

A

Now you know issue templates. They came about in 2016 as the solution for the an open source problem where a community really wants to provide feedback on how a project can improve, but you really need to have the same context for each item so that you can actually turn into action, and the same thing is true in a large organization where you want to encourage inner source.

A

You know other teams want to make sure that when they have an idea for your area, you can actually action it and make it possible, and so we found that using templates really helps kind of codify. That the other great thing about templates is. It can automatically include labels when you open an issue so you're categorizing and organizing ideas easily and uh something else we've kind of discovered through using templates.

A

Is it really helps you codify as a squad like what have you agreed should be in an issue, uh so I have an example of this here. So after a retrospective, we talked about how we could have clearer user stories, and uh this pull request kind of came as a result of that where we were talked about how we should probably include who's the target user for the story uh to really help people, you know get into the user's shoes and have that empathy and then in our functional kind of requirements.

A

We wanted to add something about metrics so that we're thinking about that up front making sure we have the right instrumentation to measure our success, and uh you know this was all facilitated through templates and now anytime, we open a user story. We have that context of of that retro uh we're reminded of all the things we agreed upon and it's just a great way to keep improving our own cycle, and so you know now we have all these ideas and issues.

A

uh Now we need to make sure that we have some scope, that we can actually prioritize against all of our other work, and this is really a place where we start to need to align as an organization.

A

We want each squad to be able to compare like apples to apples when they're planning and so we've standardized on what we call epics, which are just issues that represent four to six weeks of scope for an epd squad uh that are problem focused.

A

So I have an example here for video uploads, uh where I have a problem statement about you know wanting to attach video files to my comments. I've got the point, people for this uh epic and I have some measure of success and uh you know we we take all our ideas and we write them into epics when we're kind of ready to start prioritizing them, and so that comes with you know.

A

Kind of the next question is okay, so you have all these ideas what's actually coming soon for issues, and I get asked this all the time as a product manager um both from people that I work with every day, as well as other epd teams at github and the best way I've kind of found to organize this is through project boards.

A

uh So I've got this organization level project board. I have all my epics and the um you know. Various columns talk about the themes what's in design, research what's coming up next and because this is an organizational project board. Anybody at gut hub can actually discover this project board easily by searching and can see what's coming up soon. So if they have any thoughts or security concerns or any context to bring about mp4 support, they can just open the issue and maybe even subscribe, so they know when they might be able to alpha test it.

A

And at that point you know, we've got our epic, it's it's queued up uh and we're ready to kind of break it down into milestones, because you know epics they're, four to six weeks, that's a long time to go without getting any user feedback, and so what we do is we take our milestones, which are just logical groupings based on you know, a release or a date, uh and we break apart.

A

What's like the actual goal of each iterative, correct version towards our epic problem, um and we personally uh don't actually assign dates to our milestones because we like to be focused on the increment and shipping it when it's ready and not necessarily the date. That's going to ship so using the video upload example. You know our first milestone is actually supporting the file type for mp4.

A

Our next milestone is about like how does that work in markdown, and these milestones help us kind of stay focused on each increment of our epoch, and so when a new, a new issue comes in, we can say: okay. This doesn't help us with this goal, so we'll just tee it up for the next milestone and it helps you kind of make those priority decisions, and so you know we've had our epic we've broken it down into milestones after we prioritized it and now we're ready to just go.

A

uh So, let's talk about everyone's favorite question once something has started which is, can you give me an update on this issue? uh You know it's one of those shoulder tapping problems.

A

You know people are excited about the work and they just want to know like you know, is that in development is it like ready to staff ship, which is when we like ship internally to ourselves before users, uh and this is just one of those shoulder tapping problems uh that can be really distracting if you're a developer and you're like I open the issue I'm assigned to it like, let me just work on it and so what we've kind of adopted to help keep everybody in the loop about what the status is is issue and pr linking.

A

So if you're not familiar issue and pr linking is this concept of when you open a pull request, you can say this pr, you know closes issue one two three, and that creates this really tight link between the issue and the pull request, which is surfaced across github and then once the pr gets merged. It actually closes the issue automatically. So you don't have to remember to like go clean it up, and this really helps limit shoulder taps because anybody looking at my issue, feature backlog board, might check out the up next column.

A

They expand the comment: support for mp4 video uploads. They see this linked, pull request and immediately can tell okay. This has proof of concept kind of appended. It's got a big do not merge label, uh so somebody has kind of spiked out how this might work, and so, when I'm looking at this pull request, I should consider like it as a proof of concept and not necessarily a final experience and I'll.

A

You know adjust my feedback accordingly um and the other great thing about this is it actually makes it really clear what in a repo is currently in flight? So my favorite thing to do in any open source project now is actually search for the issues that have link pull requests. So you can do this today.

A

uh There's a qualifier called linked pr, and I just you know add this to is open like linked pull request, and I immediately see all the work that's currently happening, and it gives you that extra sense of status like what's actually in flight, and this works really great for individual issues like on your team, when you're looking at your project board, but we have to think back to the github organization as a whole. How do we keep everybody aligned on the status of epics at any given time, and so as an organization?

A

We have this concept, we call status, update comments and a status update comment is just a comment on the epic that talks about. You know whether it's green on track. You know, yellow there's some risks, a red, you know, there's a big block or an impediment, so we're working, and then it includes a demo of the current functionality.

A

uh So we have this saying no demos, not memos, because you could spend all this time writing up what something is and what a current state is, but there's nothing like seeing the actual end user experience uh and being brought to life, and you can immediately tell like how far it is in the development cycle- and you know demo doesn't have to actually be something in production. It could be, you know a design, prototype or wireframe.

A

It could be something in a development branch like in this example, or it could actually be something in production, and this is how we check in with each other, on any blockers any risks and have a place that we can start to provide feedback to each other or share with our external users to get their feedback.

A

You know, but again the scale of github 2000 people writing these status update comments on their epics, like how would the leadership team know what's important for them to take a look at, and this is where we've actually kind of adapted actions a bit. So we have an action that runs on our epics and it generates. This report comment and calculates some things, so it checks our work in progress limits for squads again, because our epd squads are really small and focused.

A

We don't want anybody to have be assigned more than like two epics, because they're trying to do too much at once, and we have to have a priority conversation.

A

It calculates you know, how long has this epic been in progress, and you know if we're hitting that six week mark. We need to maybe have a conversation about. How can we split this epic into more epics um so that we're having more increments and check-ins, or is there some big big risk that we identified through investigating this particular problem and it also aggregates all those red and yellow statuses for the leadership team so that they know what is actually most critical for them to pay attention to?

A

And you know we just keep keep doing this until we're ready to. You know flip that feature flag on for our users through beta or uh to actually deploy as a general availability feature, and you know here we are coming up on time. So quick recap of everything I just talked about going back to that chart.

A

I've got my ideas they're all in issues I'm using templates to categorize them make sure I have enough context from everyone, I'm scoping them down and then, as an organization we're aligning by using this like four to six week, epic template uh that is focused on problems.

A

We prioritize those problems for each squad and then pick up the thing. That's next and then, as we're iterating through you know, breaking that epic down into milestones and sharing our demos with each other, we're learning we're building more and iterating on the final end user experience we release it and then we get great feedback from our users. That starts that cycle all over again.

A

uh So I'm super looking forward to your questions and you know thank you so much for listening.