GitLab Plan Stage, 24 May 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How the Plan team uses GitLab for Planning

Description

Thomas Woodham (Engineering Manager, Secure) and Sean McGivern (Engineering Manager, Plan) talk about planning at GitLab, using GitLab.

A

I'm just looking for workflows, sir okay.

B

Alrighty so yeah- oh sorry, hey yeah, so just for the purpose of the video I'm Shawn I'm, an engineering manager for the plan back in teammate, get love I'll I'm here chatting with Thomas the engineering manager for secure vacuum engine. Anything cool and Thomas you've got some data. You want to collect from other teams, basically yeah.

A

Ok, so the reason that I am so the question that I'm coming to for this call is: how do other teams use the planning features within gitlab to effectively plan their next releases? Now? So that's the. If that's the data point here is the pain or the problems that we're experienced it. We then secure that has been mitigated a little bit recently, but at the same time, we're still struggling in that within the secure stage.

A

We're effectively tracking seven top end features with seven engineers, and the reality of it is is that each of those fixed features require a different skill necks. So it makes it hard to use one board in order to effectively plan out and do a priority order, and just I mean we can't do Kanban style, which to me is the way is what the plan issue the issue boards lend themselves to. So you just pick.

B

At pick anything off the top yeah yeah.

A

We can't because not only do do the features require different skills. What it's led to is that the skills held by the engineers on the team are unevenly distributed, so so with all so. Inevitably, what's going to happen is I'll have engineers who will be looking for the next feature to pick up in the Tri rower and they can't because they don't have the skills necessary to effectively resolve the problem.

A

So this particular problem for a pain point for us has been mitigated somewhat in that we have split the stage into two back end engineering teams allowing each team to effectively focus on three or four things, as opposed to every engineer having to focus on seven things, so that will allow us to more.

B

A

Between those two teams, right, yeah, there's a clean cut and what there's some shared aspects of it? We're working that working that part out, but what it's going to allow us to do is to specialize a bit more and it should even out the skills matrix on each individual team as we move forward, but it's still I'm still left with that same question, how are other teams using the features within get lab to plan their releases, and can we learn from that and do better ourselves? So that's that's what I'm coming with sure.

B

So the the first thing I should say is that we don't have the same problems. You do the same challenges you do in the sense that, in terms of the stages that get lab and what the sort of technical requirements for each of them like plan is one where it's it's a fairly modulus skillset. That's needed so like there is expertise needed in different areas, but there's a mostly X like other domain expertise or the technological expertise is like something that's quite easy to share.

B

It's not the case where, like you know, you have, we don't normally have a case where, like there's literally like one or two people on the team who can work on this thing so right now it seems ten people most of them can work on most things very, pretty effective base. That makes a lot easier, so we've got a few different ways. We plan things so I'm just gonna share my screen, real quick that will probably help them as well yeah.

B

So what we do is we go from so each of these is in priority order and we go from right to left. This is just the product manager, so the big problem we have is that we want to get that Kanban style, but, like the only place at the moment, you can drag and drop it issues is on the board and this monitors no, not tiny.

B

It's reasonably big, but I can see like what one two three four five six issues on the screen at once, which is hard to do prioritization with so the PM, like you know, will put things over here so, like you know, bugs will typically be higher.

A

B

Than technical that typically higher priority than general features, but they can put like specific feature labels. They can move the list over here if they want to. So they have a this time, but they can do in general and then from a back-end perspective. It is pretty much just a classic.

B

Sort of conman style that you mentioned, where we just well I use this board mainly just to see what people are working on, but it's also useful for seeing what's left. So what this board shows is just like the list of issues in priority order. So that's like re retrofitted from the previous one, because, like the different lists, don't have a relationship to each other, so I could go and drag these around manually and then we can see what each person's working on and yeah go from there.

B

So the idea there is that, like this, this board is just scoped to back end and then it has assignee lists. So it's more for me to use as a manager to see like okay, well, who's got. What on at the moment like there's someone overloaded, there's someone under loaded or if someone's going on vacation, like you know, maybe maybe they should be trying to like wrap stuff up rather than take new stuff. One thing we're actually adding this release relating to what I was just saying.

B

Is that so we're gonna add a manual option to the issues list page so, like you know Paige, so this will show you the sort, the same sort order that would be in the board and then from this you'll be able to drag and drop and do the same ordering that you could do in the boards, because at the moment that ordering is global across the entire project or group. In this case it doesn't depend on the board you're in.

B

So that's that's what we're doing to make that easier as well, because these are you can fit more on the screen here and then, if you can drag these around, then you can take that order to the boards or the order will take us to the board automatically and you'll you'll.

B

Be able to do that better so, and it will also display a hundred issues at a time when you're in manual sort instead of the default twenty just to make that easier as well, because, obviously with twenty, even with a hundred but like it, reduces the problem with twenty. The problem is, if you want to move issue 21 to reposition twenty like how do you do that, because they're on different pages? So that's that's the main way we work in terms of like what would work for secure and it's hard for me to say, I.

B

A

You're, real quick, so this is great from as far as monitoring execution within it isn't within.

B

A

Release and it speaks to what PM is looking at from prioritization couple of questions, one and I'm, showing my naiveness on how the boards work here sure.

A

So my understanding is that each column, so so so each column is based off of one thing, so in this case, you've got it based off of assignee, as opposed to tagged as an exam. Although.

B

You can mix them, so we've got one here for right at the end for community contributions, so, okay, basically, if a member of the wider community is working on an issue, we want to track that in our milestone. But we don't want it to show up in this list, because people shouldn't be trying to pick that because somebody's already working on it and normally for those, we also don't care so much if they slid okay because they weren't scheduled in the first place.

B

Normally, they were just like something that somebody from the wider community decided to work on. Okay,.

A

And by also understanding is that an issue will show up in one and only one column, no.

B

Yeah, let me find so. If this is you once assigned to Felipe and yaker I would show up them both the same for labels, the only ones where you can guarantee that they will only show up in one column are when you are using these scopes, labels which are mutually exclusive or when you're using a milestone list, which again an issue, can only have one milestone, so okay, property of the the field that you're using to set the column, not our property of the board itself. Okay,.

A

All right, thank you. Yeah I was my. My understanding was wrong. So that's what I wanted to ask? Okay. The next question that I have is when it comes to actually doing release planning itself.

A

How are you working with p.m. from these boards to understand what you can actually commit to doing versus what you're going to aspire to do? Yeah.

B

That's a good question, so we mostly use wait and I. Don't think we haven't documented anyway, but it's basically just like you know. Sort of basic like one is like super trivial, like probably takes that much time to write the issue as it does to fix the issue to is, like you know this jib, it should take. You, like you, know a small amount of time, but isn't a major issue. Three is you know this is a. This is a fairly substantial issue, but not like it's not gonna take ever be a whole month.

B

It's like you know, you're gonna be able to do a few of these in the month. But you're, not you know it's not trivial and five is. This probably will take over a good chunk of your month and anything bigger than five. We try and avoid. Basically, so you know it's not scientific, it's just to give us an idea of capacity overall. So we don't really care about the weight on these assignee lists as much as I care about like just when we start the milestone, how much total weight do we have?

B

How much does that? How does that compare to previous milestones- and one thing we've not been doing- is tracking this very well, except in like Google, Docs and stuff I. Think it's something I probably want to add to our handbook page or something in the future, to give a better idea of like what our capacity is, but that's the way we do it so another feature actually talking about adding is.

B

This line, you know oh yeah,.

A

The capacity line- okay, yes.

B

So chrome chrome remembered redirect from Google for that issue. Instead of.

A

B

Issue but yeah, like you, know, just adding this line. That says like okay. Well, this point is where I think pasty is for this. This.

A

B

So it's not scientific at all. Like you know, this is not like, based on a huge amount of data. It's just based on like iterating and like seeing. What's there. As we add more people as well like it becomes hard to balance that, because you I think I can't I was talking. Somebody else about this yesterday, like you, almost need like a model for like when someone new joins the team, because that you can't just increase your capacity by like one person immediately like phase it in overtime right like their first month.

B

They're, probably not here for the whole month, know getting on with everything. They've got a bunch of onboarding tests to do that, they're, trying to figure out how the code base works.

B

You know, and then months they're getting a bit more into it, and then months like three four five and six, like you, know, sort of become more regular months, so yeah there's we don't have any model for that. It's.

B

Just like what happened previously, I, don't think we've ever added more than one person in a new month, which has also helped with that so yeah, and what I would really like to do eventually is just do it based on issue count and be confident that all of the issues are small enough weights that it doesn't matter like you know which issues you pick up like I'm, definitely seen like people suggest, so you can see. For instance, this bug has weight three, and this book has 22 I've never seen.

B

People suggest that all bugs should just be like the same way, because you have a known like exit condition from a bug which you don't necessarily do for a feature like it's much more well-defined, but I haven't done that understood so yeah and then from the front end like they do the same thing. So this board is scoped by the backend labeled, but for the front-end maid they do the same exercise.

B

I, don't know if they use the weights in exactly the same way, but they figure out like what I see from the front-end manager is like. They will say, like we have this much weight. We reckon we can take this much weight. We are under / over for this, this milestone, but the numbers are sort of deliberately opaque in that sense like as long as they're consistent for each team from month to month, it doesn't matter that they consistent across teams so much okay,.

A

Alright, so traditional agile, velocity planning poker because we're equivalents.

B

A

B

Here, I weight most of the issues myself like I, try and involve the team more, but just because, like I've, been at get lab for a while and I have a lot of context for all these issues. Sometimes I just think. Well, you know, maybe it's easier for me to do this. The runs and interrupt my team, but a nutri medical team or because sometimes they get it quite badly wrong.

B

Normally, on the other side by everything, I read a post about this recently like how, because the effect of overestimation is like bounded so like, if you think, something's gonna take three days and it takes like one day like it can take that less than zero days right yeah, but it's unbounded on the other end, like the mean, tends like way higher.

A

B

Of that, because, like you, might expect something takes a week and it takes a year and all of a sudden that just completely blows out the the mean for your estimations there so yeah and then there was gonna, be another point: I was gonna, make there, which I've never forgotten so I'll come back to you.

B

Sorry right now, I think I derail myself. No.

A

You're, good, okay, RT so restating what I think I heard so right now using weights and you give.

B

A

Some idea, but of what total weight the team can take on in a given month and as long as everything is in priority order, you'll you can determine if you've got too much or if you got two little based off of how things been weighed and then therefore, that's not you know where she commits to yeah.

B

And the nice thing about the pic of thing off the top of the list style as well is like you, don't need to care so much if you've got exactly the right weight and capacity, because if you were a little bit over optimistic- and you can't actually do everything in this release like if we don't get to decide some way at the bottom here, it was way at the bottom. We'll put it at the top of the next release. But it's not like yeah.

B

That's not a catastrophe like the product manager has already put the issues in the order that they've determined like highest priority, and then it's our job to like you know, make that reasonably predictable for them. That, like, if I put this at the top of the list, it will be done like sooner than something at the bottom of the list, essentially okay, because because obviously like people won't necessarily always pick the exact top item like sometimes they might go down wanting to, because you have the whole thing where this might be.

B

Wait three for one person and wait five for somebody else, because they don't know how our graphical implementation works, so it takes them longer than somebody who's already used it. For instance, okay,.

A

Yeah do do you have any issue? Do you allow any issues to come into a release that spam teams in what I mean with that back-end front-end work of the require to deliver it.

B

So sorry, issues that span the backend and front-end team. Yes, yes, but.

B

We try to actually that shouldn't have front and we try to limit those so in this case at cheaper, it's got to so you can see that there's front-end engineer assigned here as well as back-end engineer in both of these cases.

B

These do have you've got the coordination problem right, like it's a lot of the time like for this one, for instance a few epic tree and epic. This is kind of issue where, like we couldn't really write the backend and then like deliver that to the front end and get them to work on it. We need to like collaborate and figure it out as we go along, because the way we were building that API was using brac ul and we were still sort of figuring out how we wanted to use that.

B

For this thing, and also the feature itself like I, think you know, we have a few questions about like how we build it as we went along, which is fine, but, yes, you can see it missed the original target, partly because of that, my extra coordination needed right, the less you need to sync up with people, the faster you can go in general, so we do have a few of those.

B

We generally find it works okay, because the priority like I said, is the same across different boards, so like if it's at the top of the back-end list up, remove you quite close to that's for the front end list. We do sometimes have issues of capacity, though yeah we're like there is nobody from back-end available to take this issue that somebody from front end is working on or actually more typically, the other way around.

B

Just as the backend teaming plan is much bigger than the front end team on plan, but yeah we do have that coordination problem. We try not to have too many issues that need both back-end and front-end input in the same release. To like avoid too much risk there, because, because like when, you have two teams working on the same issue, that that increases the risk which people talk about yeah, yeah.

A

Yeah, okay, do you take the step, and this is procedurally, this is I mean this is a procedural question. Do you take the step of naming someone to be a single directly responsible individual for things that span front-end and back-end.

B

That's a good question so.

B

Let me just I'm slightly different Russian. First of all, yeah so I know that some teams that get lab like pre-assign issues. So instead of doing like this, where, like anybody, can just pick anything, they will say like okay, well, Felipe's gonna, take this issue. Yahoo's gonna, take this issue. Brett's gonna take this issue and so on.

B

We don't do that generally, but for these issues that require coordination, we do try to get those assignees like if they're near the top of the list, and they need back in and front-end, which you try and get those assignees locked in fairly early and I would say.

B

Typically the person owning it is the person who is doing the most work, if that make sense. ah So so I think this issue is slightly bigger on the back end and the front end. So the back end engineer is owning it, for instance, that's sort of how it's worked out in practice.

B

You might also just say like what sorry excuse me, you might also just say: well, bacchanal typically owned it because they are blocking front end or front end will own it, because without the front end the future can't be done, or you might say, whoever's. The most senior will own it, but we don't have a formalized process around that, but yeah from my perspective, I'm always just going towards the back end engineer about it well, I say always. Obviously, I will towards the front end engineer about it.

B

But from my perspective like what I care about is like what my team are doing and they are I will consider them the DRI for the issue, even if they consider themselves blocked on somebody else. Basically, okay,.

A

Yeah yeah I, underst yeah. This is an idea. That's been rattling around in secure it's like do. We go to the point of naming a directly responsible individual for every single issues, whether I mean obviously there's one assignee you're it, but if there's two three or four assignees who's really running this show yeah.

B

And for this one as well like there's, three assignee is because there's also the UX the product designer, and they will have a big input here as well, because they'll also be involved on the EMR, and they have been saying, like you know. Well is do we need to include this like? Is this a scope thing, or is this a keep thing like? You know, I think it should work like this, so it's yeah I see where you're coming from, because with three people.

B

Obviously there's there's definitely a case for everybody to think a bystander effect right now. I really think somebody else is the DRI okay.

B

A

B

Basically, I think what I said is like how we do things and also why that might not work for secure she's tried to do that directly, because you have like some additional challenges that we don't have, but if you have any features or any questions about how this part of the product works or like you want it to work in a different way, one of the great things about working on a product like get lab that you use every day is that you could.

B

You can like submit to feature proposal or whatever and say like well, you know I I needed to win it this way and I'm an internal customer there's a label for that. That means my. We should treat it as a high priority. So you know it's not just like yeah you're sort of giving feedback to a company- and you know know if it's gonna be resolved, you giving feedback to your own company and it still might not be resolved. But you have you have more visibility process, yeah.

A

Yeah and I think we wrote eeing the point where I'm ready to start doing some of that at this time on I want to learn in context, because you know there's a definite opinion on how everything has been built thus far and I'm, making better. That I understand the context in the opinion of, what's there to to see how it meshes with my own thinking and if I need to change first. So that's yeah.

B

Also, just a personal perspective, not it's like the plant engineering manager, but just a sort of a general engineering manager, I quite like that different teams can do this slightly differently. We all have the same like expectations in terms of like dates. Like you know, our milestones or a month long, you know feature freeze day is the same for every team, but we don't have to do exactly the same process in each team, because that lets us like find the process that works best for each team.

B

I think it's I think it's more important to have the right process that works for the particular team than it is to have the same process as every other team agreed.

A

Agreed but the tooling can help her hurt depending your point out for absolutely.

B

Like if your process needs like well custom fields, for instance, then you have a hard time with that we'd get lab because we have labels, but we don't have custom fields right now: yeah yeah.

A

Agreed: okay! Well, this answered my questions at the moment, sir awesome, so thank you. I I'm gonna hold you to a handbook entry on weights and guidance and how you, how you're, using them, yeah.

B

Thank you, yeah I'll, just personally quick on the plan page because I don't think it applies across different teams, but I'll just be saying like this is how we at the back end, use these weights, and then people can see that and also as I hand this out to the team as well like. It gives me a point where I can say like well. Can you wait this according to these rules, rather than what I'm doing which is saying like? Can you wait this cool?

B

It's these rules, I've just told you in slack, which is not really how we're supposed to communicate. You get love yeah,.

A

Yeah yeah, yeah, agreed and I was always defaulting to the same way. The way that I would just to share the way that I was interpreting weight was was a definition was was, is really what a brought over from previous previous company the? What I was doing it before and I was anticipating it awaits to be person days or engineer days would be a better way of looking at it and where I was asking for t-shirt sizes. Is this extra small, it's a small, it's medium large, all the way to double, XL and and.

B

A

A common understanding of sex you're small- this is gonna, take a day, that's small! This is two days. It's medium. It's gonna take a week and so forth. You see where it's going from there yeah using that for weights, but it that it's not translating well um and so I wanted to see how you're using it and see if there's a way that I could adapt and make our planning process easier because, right now it's um we're not doing it. Well so yeah.

B

A

B

Just don't that last point real quick cuz, you know I've got another meeting coming up, yeah and yeah. Well, probably say: music.

B

The the thing with days I, find it get lab, is because we're so asynchronous have asynchronously focused. Is that it's hard to predict when a particular mode request will be necessarily merged or which means when a particular issue will be closed, but we are very efficient at getting sort of bandwidth through, like not so much latency for a particular issue.

B

Well, bandwidth is very high and that's why I like times I, think kind of a hard concept for that, because, like once you hand it over to somebody for review or somebody to like work on the front end for it like? Are you expecting them? Probably the same timeline? It's kind of fuzzy, yeah.

A

Yeah and that's and that's what I was running it into exactly you stated it much more elegantly and efficiently than I could at this point, hadn't even implicit, endpoint down the language just yet, but good thing, but ya know this is good. This is helpful. Awesome.

B

Well, thanks very much Thomas I'll post this on youtube very shortly. Okay,.