169 lines
13 KiB
HTML
169 lines
13 KiB
HTML
<div><p>
|
||
At GitHub we use GitHub to build our own products, and the new
|
||
projects experience is no different. Check out how our team uses
|
||
projects to build powerful project planning for developers.
|
||
</p><img srcset="
|
||
https://github.blog/wp-content/uploads/2022/05/blog-header-image.png?resize=800%2C425 800w,
|
||
https://github.blog/wp-content/uploads/2022/05/blog-header-image.png?resize=1400%2C742 1600w
|
||
" src="https://github.blog/wp-content/uploads/2022/05/blog-header-image.png?resize=1400%2C742" alt="How we’re using projects to build projects"/><div>
|
||
Author
|
||
</div><img src="https://avatars.githubusercontent.com/u/526284?v=4&s=200" alt="Jed Verity"/><div>
|
||
<time datetime="2022-05-16">
|
||
May 16, 2022
|
||
</time>
|
||
</div><p>
|
||
At GitHub, we use GitHub to build our own products, whether that
|
||
be
|
||
<a href="https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/">moving our entire Engineering team over to Codespaces for the
|
||
majority of GitHub.com development</a>, or
|
||
<a href="https://youtu.be/MW0V5Q9WJu4">utilizing GitHub Actions to coordinate our GitHub Mobile
|
||
releases</a>. And while GitHub Issues has been a part of the GitHub
|
||
experience since the early days and is an integral part of how we
|
||
work together as Hubbers internally, the
|
||
<a href="https://github.blog/changelog/2021-06-23-whats-new-with-github-issues/">addition of powerful project planning</a>
|
||
has given us more opportunities to test out some of our most
|
||
exciting products.
|
||
</p><p>
|
||
In this post, I’m going to share how we’ve been utilizing the new
|
||
projects experience across our team (from an engineer like myself
|
||
all the way to our VPs and team leads). We love working so closely
|
||
with developers to ship requested features and updates (<a href="https://github.blog/changelog/label/issues/">all of which roll up into the Changelogs you see</a>), and using the new projects helps us stay consistent in our
|
||
shipping cadence.
|
||
</p><h2>How we think about shipping</h2><p>
|
||
Our core team consists of members of the product, engineering,
|
||
design, and user research teams. We recognize that good ideas can
|
||
come from anywhere. Our process is designed to inspire, surface,
|
||
and implement those ideas, whether they come from users,
|
||
individual contributors, managers, directors, or VPs. To get the
|
||
proper alignment for this group, we’ve agreed on a few guiding
|
||
principles that drive what our roadmap will look like:
|
||
</p><p>
|
||
💭 <strong>The pitch</strong>: When it comes to what we’re going
|
||
to work on (outside of the big pieces of work on
|
||
<a href="https://github.com/orgs/github/projects/4247/views/7">our roadmap</a>) people within our team can pitch ideas in our team’s repository
|
||
for upcoming cycles (which we define as 6-8 weeks of work,
|
||
inclusive of planning, engineering work, and an unstructured
|
||
passion project week); these can be features, fixes, or even
|
||
maintenance work. Every pitch must clearly state the problem it’s
|
||
solving and why it’s important for us to prioritize. Some features
|
||
that have come from this process include
|
||
<a href="https://github.blog/changelog/2021-10-27-the-new-github-issues-public-beta/">live updates</a>,
|
||
<a href="https://github.blog/changelog/2021-10-27-the-new-github-issues-public-beta/">burn up charts for insights</a>, and more. Note: these are all the changes you see as a
|
||
developer, but we also have a lot of pitches come in from my
|
||
fellow engineers focused around the developer experience. For
|
||
example, a couple successful pitches have included reducing our CI
|
||
time to 10 minutes, and streamlining our release process by
|
||
switching to a ring deployment model and adding ChatOps.
|
||
</p><img src="https://github.blog/wp-content/uploads/2022/05/pitch-image-1.png" loading="lazy"/><p>
|
||
💡 In addition to using issues to propose and converse on pitches
|
||
from the team, we use the new projects experience to track and
|
||
manage all the pitches from the team so we can see them in an
|
||
all-up table or board view.
|
||
</p><img src="https://github.blog/wp-content/uploads/2022/05/pt-pitches-image-2.png" loading="lazy"/><p>
|
||
✂ <strong>Keep it small</strong>: We knew for ourselves, and for
|
||
developers, that we didn’t want to lock them into a specific
|
||
planning methodology and over-complicate a team’s planning and
|
||
tracking process. For us, we wanted to plan shorter cycles for our
|
||
team to increase our tempo and focus, so we opted for six-week
|
||
cycles to break up and build features. Check out how we recommend
|
||
getting started with this approach in a
|
||
<a href="https://github.blog/2022-02-11-getting-started-with-project-planning-on-github/">recent blog post</a>.
|
||
</p><p>
|
||
📬 <strong>Ship to learn</strong>: Similar to how we ship a lot of
|
||
our products, we knew developers and customers were going to be
|
||
heavily intertwined with each and every ship, giving us immediate
|
||
feedback in both the private and public beta. Their
|
||
<a href="https://github.com/github/feedback/discussions/categories/issues-feedback">feedback</a>
|
||
both influenced what we built and then how we iterated and
|
||
continued to better the experience once something did ship. While
|
||
there are so many people to thank, we’re extremely grateful for
|
||
all our customers along the way for being our partners in building
|
||
GitHub Issues into the place for developers to project plan.
|
||
</p><h2>How we used projects to do it</h2><p>
|
||
We love that the product we’re building doesn’t tool a specific
|
||
project management methodology, but equips users with powerful
|
||
primitives that they can compose into their preferred experiences
|
||
and workflows. This allows for many people (not just us engineers)
|
||
involved in building and developing products at GitHub (team
|
||
leads, marketing, design, sales, etc.) the ability to use the
|
||
product in a way that makes sense for them.
|
||
</p><p>
|
||
With the above principles in mind, once a pitch has been agreed
|
||
upon to move forward on building, that pitch issue becomes a
|
||
tracking issue in a project table or board that we convert into
|
||
pieces of work that fit into an upcoming cycle. A great example of
|
||
this was when we
|
||
<a href="https://github.com/github/roadmap/issues/289">updated the GitHub Issues icons</a>
|
||
to lessen confusion among developers. This came in as a pitch from
|
||
a designer on the team, and was soon accepted and moved into epic
|
||
planning in which the team responsible began to track the
|
||
individual pieces of work needed to make this happen.
|
||
</p><img src="https://github.blog/wp-content/uploads/2022/05/issuereasonsfinal.png" loading="lazy"/><h3>IC approach</h3><p>
|
||
Let’s start with how my fellow engineers, individual contributors
|
||
and I use projects for day-to-day development within cycles. From
|
||
our perspective on any given day, we’re hyper-focused on tackling
|
||
what issues and pull requests are assigned to us (fun fact:
|
||
<a href="https://github.blog/changelog/2022-02-23-the-new-github-issues-february-23rd-update/">we recently added</a>
|
||
the <code>assignee:me</code> filter to make this even easier) in a
|
||
given cycle, so we work from more
|
||
<a href="https://docs.github.com/en/issues/trying-out-the-new-projects-experience/quickstart#creating-a-user-project">individually scoped</a>
|
||
project tables or boards that stem from the larger epic and
|
||
iteration tracking. Because of this, we can easily zoom out from
|
||
our individual tasks to see how our work fits into a given cycle,
|
||
and then even zoom out more into how it fits into larger
|
||
initiatives.
|
||
</p><p>
|
||
💡 In addition to scoping more specifically a given table or
|
||
board, engineers across our organization utilize a personal
|
||
project table or board to track all the things specific to
|
||
themselves like what issues are assigned to them—even work not
|
||
connected to a given cycle, like open source work.
|
||
</p><img src="https://github.blog/wp-content/uploads/2022/05/glorthopersonal-image-5.png" loading="lazy"/><h3>EM approach</h3><p>
|
||
If we pull back to engineering managers overseeing those smaller
|
||
cycles, they’re focused on kicking off an accepted pitch’s work,
|
||
breaking it first into cycles and then into smaller iterations in
|
||
which they can assign out work. A given cycle’s table or board
|
||
view allows the managers to have a whole look at all members of
|
||
their team and look specifically at things that are important to
|
||
them, like all the pull requests that are open and quickly seeing
|
||
which engineers are assigned, what pull requests have been merged,
|
||
deployed, etc.
|
||
</p><p>💡 Check out what this looks like in our team board.</p><img src="https://github.blog/wp-content/uploads/2022/05/backlog-image-6.png" loading="lazy"/><h3>Team lead approach</h3><p>
|
||
Now, if we put ourselves in the shoes of our team leads and
|
||
Directors/VPs, we see that they’re using the new projects
|
||
experience to primarily get the full picture of where product and
|
||
feature development currently sit. They told me the main team
|
||
roadmap and backlog is where they can get questions answered like:
|
||
</p><ul><li>Which projects do we have in flight in which product area right
|
||
now?</li><li>Who’s the key decision maker for this project?</li><li>Which engineers are working on which projects?</li><li>Which projects are at risk and need help (progress/status)?</li></ul><p>
|
||
What’s great about this is that they can quickly glance at what’s
|
||
in motion and then click into any cycles or status to get more
|
||
context on open issues, pull requests, and how everything is
|
||
connected.
|
||
</p><p>
|
||
💡 Outside of being able to check in on what’s being worked on and
|
||
where the organization’s current focus is, our leads have found
|
||
additional use cases that may not be applicable for an engineer
|
||
like me. They use private projects for more sensitive tasks, like
|
||
managing our team’s hiring, tracking upcoming start dates, making
|
||
sure they’re staying on top of career development, organizational
|
||
change management, and more.
|
||
</p><h2>Wrap-up</h2><p>
|
||
This is how we as the planning and tracking team at GitHub are
|
||
using the very product we’re building for you to build the new
|
||
projects experience. There are many other teams across GitHub that
|
||
utilize the new project tables and boards, but we hope this gives
|
||
you a little bit of inspiration about how to think about project
|
||
planning on GitHub and how to optimize for all the stakeholders
|
||
involved in building and shipping products.
|
||
</p><p>
|
||
What’s great about project planning on GitHub is that our focus on
|
||
powerful primitives approach to project management means that
|
||
there is an unlimited amount of flexibility for you and your team
|
||
to play around with, and likely many, many ways we haven’t even
|
||
thought about how to use the product. So,
|
||
<a href="https://github.com/github/feedback/discussions/categories/issues-feedback">please let us know</a>
|
||
how you’re using it and how we can improve the experience!
|
||
</p><div>
|
||
<span>Tags:</span>
|
||
</div></div> |