GitLab Plan Stage, 7 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Custom workflows and value stream management

Description

Brief notes: https://docs.google.com/document/d/11puPPod4FpiWZp4UCOX-e2hy3QyPVgNlpXw_5xEzExY/edit

A

Great okay, so one thing that we talked about would be SM, which is really interesting or started with we're closed is that we know we're gonna build the SM in the future, so one thing that we've been talking about really wanted to to just get your thoughts on. Is that we're we're really leaning toward calling not calling this custom workflows for a number of reasons? One of them is just an obvious reasons like we don't call them.

A

Custom labels or custom milestones or custom whatever, as the Sean brought up hey Eric, so I'm just bringing mark up to speed really quickly on the valley, workflows concept, and so we we knew or, as our designer Annabelle was working on this. She she started doing some designs and really hit me, or maybe she knew all along, but that these were really building. Our goal is not to build custom workflows. We can think of it as a mean scent and to build value streams. So we're really excited army.

A

I'm really excited that I think we should just call this value, workflows or maybe like business value or just something just take a little word custom and really emphasize like the business and the value and those sort of buzzy words. So just just wanted to share that with you and you have any immediate thoughts on that. Yeah.

B

I totally agree, I think that I'm really excited by this whole thing because of the value stream, stuff, I, don't know next year. What you should call it per se, but doing hit something with value stream actually does make sense, like even workflow, is, to some extent the synonym for stream and so like.

B

If you just said actually what we're doing is letting you define your value stream, because I'm sort of just jump to the end result instead of sort of going through, oh well, we're actually just doing explain to ya we're jumping to the definition of a stream. Thank.

A

You so all right, so, let's, let's jump into the to the meat of the discussion, Erica I'm, already recording you might notice so I put the stock together. It's in the agenda. I just put this together Eric this morning, so you might not see it yet, but it is in the agenda and mark already clicked in so thank you Mark, so really quickly. I lied a couple points why I think doing it with you.

B

Jump in, though, is everything: that's here already covered it in the issue before the comment, or is this there's there new information here.

A

There is I think a lot of this is rehashed, but just I mean at the end of this meeting. I'll definitely attach this like. We should just delete this document gosh and then I'll attach all this to the issue, but I try to read just put my all my thoughts together and summarize so so to me, it's the analysis of any product implementation. We should analyze in a couple ways just just just how the user experiences it. You've talked a lot about small parameters being a strategic approach to a lot of building product in general.

A

So when, when I, when I think about the word strategy- and you know it's really about to me- how much time does it take to to build a feature now or not time, I really effort? How you know is it? Is it good for iteration? Are we mitigating risks, long term, how it doesn't make sense to continue to maintain it or how? How much effort it takes to maintain?

A

Are you introducing more complexity, so I wanted to address all those points and I try to laid out all those here and then, for example, I said user experience. Overly loading labels has been confusing with its many uses up to now, I think a first-class experience is a better intuitive experience and then also the flip side. It's not just about creating workflows. It's about creating maintaining labels, which you know people have complained for many good reasons, and so it you're interrupting labels as well.

A

It's not just about work clothes, so user experience, I think, is a key key point. Effort required to make the feature the initial effort. I think it's actually takes more effort to do build it on top of the labels, because precisely you have to build on top of labels, and you know you like. Okay, you get certain things for free, but I'll talk about why that's actually not relevant, but definitely you have to you add things into the sidebar. You have to add the so.

A

So the only thing you get clinical for free with labels is just the object itself. So so I will definitely agree with that, but overall, as a feature as a mV, for example, just two. So the way we've carved up the embassy it from a design perspective is just two things right and you need to configure it somehow and you need to show it on the issue display like the issue page and so, for example, you don't need an issue board right that definitely does not MVC, you don't need any type of VSM.

A

You are right, so as an MVC, all you need to do is so so. This current plan is to build it from a configuration screen and we've chosen group, and we can talk about that, maybe even as separate content. We want to do it in groups for now it's not projects, and so we need some type of configuration there and we'll probably ship that maybe put that behind a feature flag.

A

If we can't do the issue display in the same milestone, but to me like just this feature, you have to have those two components and having those two components with labels means you have to do all that work anyway. So I don't see a huge work, a huge benefit, if any to do it with labels. Effort required to do the SM I think is the biggie here because same points as above.

A

But the really salient point is the timing, and we've talked a lot about this in the past six months, if not longer, with really nailing it down with labels, because we thought the the history is that we we wanted to build VSM on top of label boards before, and so we spent a lot of time talking about labels. We spent a lot of times talking about. Well, if does label belongs to a board, then we consider it a workflow label and so on and so forth.

A

So there's a lot of complexity to maintain there and initial effort required to categorize a label as a workflow label and then to add timing information to that. So there's effort involved there to make that work as opposed to using in a first-class object. Then then, it's separate long term effort to maintain feature. Obviously the downside is just there's more nor more things there. If you introduce a new abstraction but we're not comparing doing nothing right, we're comparing to building more things right.

A

So when you're, building more things you're by definition, there's more code to maintain and so I would argued. Are you would you like to maintain more code with a new abstraction, or would you like to maintain more code with an existing odd checked that it has more use cases more edge cases more like no labels, you can have project labels group labels. Now you can work for labels.

A

You have labels in the admin, there's these things and min labels and how people know about, but they're like configured for instance, and you copy them when you create a project. So there's all these additional edge cases. If you want to build on top of labels and then finally, I wanted to emphasize and I'm going through this really quickly mark, because I didn't want this to be discussion and finally, I wanted to mention that duplicating similar functionality for labels. I think that's the greatest argument for small primitives.

A

The concept in this in particular, so I thought about this again very deeply and I. Don't think there's a lot of benefits here so so with in the contrast. I thought a lot about is for custom fields, I think that is so. That's why I'm you know I'm not totally convinced feed on labels is. This is the answer. Is the first iteration but I'm willing to put that as the what we've stated, as as the next iteration out there and give lab, and then we can continue to argue as we get closer.

A

But to me custom fields is: is a lot is something to be argued more because they're, just like labels right, you're, just tagging, something as a field and then there's this additional thing about. You know maybe mutual exclusion and then a little bit more constraints but they're, essentially labels in like from a gut feeling or, however, you want to analyze. I think we would all agree but workflow stages to me. There's something separate, they're more akin to a milestone, a weight assignee.

A

These are different attributes to an issue, so they share similarities to labels from that comparison. But the features and use cases are so separate. So, for example, if you reduce small primitives benefit, is that filtering by issues by a label filtering issue by assignee. You get that for free, quote: unquote right! You get that for free with system notes. You get that for free. Where else in the issue sidebar right. Do you get a lot of things quote-unquote for free in the, but on closer examination, with workflow stages, I think system.

A

Note is the only thing that you really get for free, if that's a small marginal benefit, and it's not even a first-class user experience, because you know you just say like added label removed label and then even that's already proven to be confusing, because people always see that with workflow boards right now with labels, and they ask questions like you know, this should be combined because you're, adding a label and removing a label. Can you indicate that this is a board label? So it's already proven to be confusing.

A

First of all, so we would need to improve it if we were to use labels and then the other proposed our purported benefit is in the sidebar. We we said that if we use labels even for key value labels, we would need to put it in a different place if we wanted it to be a stage and again that's true for like a really really small MVC, but the next iteration you probably want, and in our current design you want that stage next to the open/closed badge anyways in the top left.

A

So you know you get the benefit for one iteration and you already have to move that to the top left. So I don't see a benefit there filtering by issue and searching it on the lists view again: I don't see a benefit there, because we shouldn't actually allow people as a design to filter by stage from there, because we should actually do it from the configuration view and the VSM view, and so animal actually has some designs there. So I can dig into those in a second by again I.

A

Don't want to dominate this conversation too much without without me. Just talking so I think I hit all the points. I really wanted to get out so I'll, let Eric and mark jump in. However, they want awesome.

B

Thanks for that, so I appreciate the thorough look at it in the balanced view, I appreciate that you you've looked at. You know the issue from a variety of angles and then come up with a conclusion.

B

The pieces that I would like to highlight that might have been missing, at least from the argument, one small piece and then three important ones. One is when you talk about the long term effort to me. Well, actually, sorry I know we talked about the we're not duplicating similar functionality for labels. One it's often forgotten about is like the API and a lot of times. The API lags for example, and so you talked about like oh you know, the only thing is that go you get system notes for free.

B

Well, you also get an API for free. You can already have you know if you were using labels, then you'd have an API for manipulating labels. You'd have a way to query it. Any workflows based on those things would already work and- and you know just be the convention of then how you use them on top.

B

But the more important issue for me is about leverage is, if you look only at custom workflows as a feature or even in this case, you've extended that to via sound, and you look at those two features and say how this works. For you know for those two features you you come to a certain conclusion because, like the bang for buck to deliver it, you know X versus Y, and you compare that you know between the two options and you might say that. Well, it's roughly speaking the same, maybe one slightly better once or not.

B

But what isn't easy to factor in is the unknown leverage and that's one of the key benefits of the small primitives. So, for example, when I paint this picture and I say, look, we've got custom workflows and it's gonna work for customer clothes and you've already talked about how you're gonna make it work for VSM. I will later concern about whether it's really going to work for VSM, property or VSM is going to need something else, but we can dig into that, but even assuming that it works for those two things, does it work?

B

For you know things outside of custom workflows like one of the nice things about label sets is just it can be used in five different features. It can be used for custom workflows can be used to enforce that stuff, but it can also just be used to you know pretty up and categorize things it can just be used for, like I want to have just multiple labels simultaneously of different kinds of things. I want a bug report to be able to have what? Oh s were you on?

B

What version where you are, and you know whatever it is, and I want just a whole bunch of different.

B

You know all the arguments for label sets and I expect that there's or at least there's a very high likelihood in my estimation anyway- that if we do this stuff for custom work, clothes like we'll, say: okay well, cut scope, we're gonna, make custom work, we're gonna only have you one thing: we're gonna call it a stage and we're gonna say like there's this one workflow label that you can apply to all issues, because that's usually how we do so, let's do it for one and then we, but then that means like great well but I wanted to have I want to be able just tag things with an OS and has nothing to do with a workflow.

B

It's just I want to tag this thing. It's all! Well, you don't have that because we cut that scope.

B

It's it's not part of workflows, so this focus I'm doing workflows means you just lose that opportunity to have a feature work for five other news cases and and and it's even like, even if you can come up with the five cases now, there's gonna be five more use cases that your customers are gonna come up with, but you just never even considered, and so for me, if it's even at all close as to which, which one is gonna, you know be like okay effort versus reward I would just heavily weight.

B

The small primitive with its higher leverage, is going to have a bigger, a much bigger bang than we normally account for, and so, like you know, if it's aren't, you argue that it's like five X, like oh, you know like let's say both of these solutions solve the same problem. Let's say they both saw them. Ideally, you know exactly saying that your face looks exactly same whatever.

B

So then it's just one effort and you're, saying hey one's a little bit less effort, but what you're missing done is, but actually the smaller, primitive isn't just solving the same. It's not providing the same bang it's providing 5x that bang, because it worked for this and for other cases, plus these other, and maybe those other cases aren't as important. So you know the calculus gets more complicated, but the point is it's a bigger bang, and so it's it's a bigger bang for potentially more effort.

B

I would also, though, argue that normally small perimeters are also less effort, and one of the other big points I wrote down is about iteration and decoupling in general, but iteration.

B

The the problem with making a first class thing is that you can do an MVC and you'll cut scope until it fits in one iteration, but the chance of that being viable in that iteration are pretty low. It's like oh well, we added this thing, but you can't do anything with it yet like it doesn't actually enforce anything. We can't.

A

Really argue specifics then, or not ours until you outline what you mean by that specifically in this case well,.

B

It's hard because I don't know exactly what your sequence is, but I can yeah well. We only have ten more minutes, though so.

A

I don't want to get too.

B

Much into it specific so I actually really like to stay at eye level and just say normally in all evidence that I've seen before when we've done similar things epics would be a good example. It took months before epics were actually usable because, like you couldn't delete, you couldn't tag them. You couldn't do these things with them.

B

We tried to make use of them, and you know I know you created several epics in the beginning, but I didn't use them for six months because they were just not viable for me, whereas if we had gone a different path, I believe we could.

A

Right I got you this point. I've explained this point to you multiple times mark epochs. We've done, we did small primitives we're epochs our issuable x' in the back end, so there are small primitives I. Don't know why you're using that as a as a proof point, this is hot like. If anything we did the opposite. They are not first class citizens, epics are not first class citizens in gitlab. They are issue of those everything in the code is repeated in the sidebar and the system notes.

A

The fact that we we did promote epoch in one shot is because and III mean like may promote epoch like the worst MVC it like. It would be like something like you would complain for sure and the fact, but then you know, York I went in and just did it and like we got everything or free right. The system knows probably the labels were promoted, the the links were from everything we got there for free and that's because we did small primitives.

A

So so, like hey, you know I'm following your arguments but but I like to then.

C

Let's clarify here so.

A

Your your your your points right, I, don't want to I want to qualify that that example is not valid. My my opinion so.

B

Let's, let's figure out how they get on that same page there, because I think it's absolutely valid and I think when we've argued this before you haven't quite said it as it's not, it is a small perimeter. You have said yeah, it's you shared code that it's an issue about I, don't know that. That's the same thing as saying it's, a small, primitive when epics were released, they didn't have an API, they didn't have. You know, that's.

A

Not that's not the criteria of a small, primitive I. Think the criteria of a small chromatid is more component wise right like there's these benefits or small primitives. Yes, but well, maybe we have to go back and define what a spot primitive is, but for your definition, for our conversation, I understand small primitives. It's really. You know we're building on top of our existing components in whether it's in the product.

B

And you confusing the fact that there's polymorphism and saying that it's a small, primitive and I agree that there's probably more fizzing going on, but there's a class hierarchy and you have shared some code. That does not mean it's a small primitive.

B

Please continue. So small primitives have banned things like in the I've got a lot of examples in the sea ICD, so I.

A

Think labels, you would agree labels for issue boards, I think you would agree on that. One like exactly.

B

That's a great small, primitive where we said we took this. You know this existing construct of labels and said we're just gonna make issue boards as another representation. On the same, you know the same data, it's just a really really small thing, and then we had to extend it in lots of different ways. Issue boards had to grow up, but they were instantly usable for some definition of useable on day one because they had some core functionality and, like all the labels, already existed.

B

All that, like you know that, like we didn't have to add a new concept of what a column header was or all these other things like. We just had labels and anyway it just it made it the whole thing faster to get there I'm, not sure. If I can explain it any better than that, but maybe we need more time to dive in, but I am going to assert that epochs were not small primitives that we did not execute in the way that I'm describing right. Okay,.

C

B

And in fact, in some ways with with these workflows, you've even said underneath we might still make them label label or whatever it is, and you might still implement them using polymorphism. The way you're approaching it is still not treating it as a small, primitive okay. So.

A

Does the Islip sorry I keep interrupting mark? Oh that's personal thing out there. It's okay I, like to rub you with five minutes left because I want to talk about next steps, but okay.

B

Fair enough so in my mind, I just see a path where you.

B

The end result, I think, will look the same roughly speaking, not the same. That's that's wrong, similar in terms of quality in terms of effect to the user, meaning like you're still gonna have a sidebar where these workflows are pulled out as separate fields, but it just it might be more generic done so they're like oh well, any key value pair is pulled out there, but some of them are an enforced workflow with a sequence, but some of them aren't.

B

Whereas if you go the other direction like I'm, not saying it's gonna be the same design. But the point is it's the same level like so when we talk about using label sets- and you say, oh well, there's a whole bunch of like UI work that we do and like well that, like the same amount of effort, can be done on either side like the UI I expect.

B

We will put this like we'll put a high bar for UI, but one of the big differences, though, is when do you have to put that higher high bar in for UI?

B

If you build a first-class entity well, then you have to build the UI before you can even manipulate it, whereas you can make an iteration with the small primitives and say: look we're not even gonna have a UI we're literally just going to use a convention of you know, foo colon bar and then we're just gonna start enforcing that in some way or we're gonna start doing you know whatever like, but you can. You can decouple everything and you can say well, let's work on. What's what's really critical for making workflows work?

B

If, in fact, workflows are the most important thing and in about like an enforced workflow, meaning you can only go from one stage to another, then we could do all that with potentially I'm, not saying it's a good idea, but we could have potentially the couple all the UI changes from that, and just just like say well, let's just enforce it in the back end first and make sure that that happens and then make UI, which means you might be able to deliver value sooner than later.

B

So I think that there's value in decoupling it allows you to iterate faster and deliver value faster and then also have leverage in particular when I would actually propose. Is that you don't like do custom workflows?

B

First, that you really just say well, look if we just do label sets first and just have a key value pair and let's leave it unconstrained and say fine, you can go and you can define your label sets where everything has to go in a certain order, but we just want to enforce that yet, but honestly, you'll deliver a ton of value to those teams that really I just want to track it, like I trust, my team, to move the right direction.

B

We can have enough process like, even if, because here's the other argument to- but this is the tangent- is that even for custom workflows- everybody's like oh, but you know this. This thing we found here: I need to go back, three steps, don't make me go and like I can do one step and then I have to do the next step and then the next step, and then I can go back. Like it's great I just want to be able to jump back there.

B

Let's do the flexible trusted thing first and then get to the custom workflows where you want to lock it down, and you only enforce that like oh well, you know he really. If you want to go from here to here, you need to have an approval process and set aside all that can be built on top of labels just as easily as they could be built on top of a first-class citizen.

B

But we can defer all that by just saying we're gonna do this smaller, primitive first, that will in fact get you probably eighty percent, of what you want, but will also get 80% of what fine of other people want, because they have these other needs, and you made this really small primitive. That was really remark.

A

Yeah, um so so I'll, let you know, know the de on the latest so per hour. Okay, are we said that we wanted mouse, remapping I, think like MVC of it sometime this year, so we moved custom fields lower in priority and then we bumped up DSM and then we've also, you know Eric suggested.

A

Why don't you just like call customer for easier, yes and which is a great idea I'm to satisfy that er, and so that's always been in the plan and because of this OPR we custom fields was always a higher priority, but we swapped, and so the current plan is in 1110. We will start work on custom work plans before this meeting. This dial is the current plan with four minutes.

A

Come I wanted to qualify that I have responses to everything that she said and so I'm not agreeing with you and doesn't take my sides as that, but I want to move four and per okay art. So what I would suggest is that instead of we actually go back to our previous plan and we actually action on key value labels right now in 1110, and we continue to have this discussion right and so that that buys this time as it were, and then it drives with your smartness concept.

A

I would right now I'm still disagreeing that key value labels goes to the SM, but I would be like you know: 70%, okay, it go into custom fields, I would be 0%, it'll go okay, going to the SM, but at least we have some functionality. I think that you would agree with, and then you could probably argue this 30% of my disagreement. Custom fields anyways. So that seems like a good way to proceed, and you know if you want to get rigorous with okay, ours I!

A

Don't really care about that too much, then we we could put this under yes em, but you know we're always changing anyway. So I think yeah.

C

A

Let that impact the decision process right.

C

So if we, if we sort of swap.

A

Back and just go back to original plan and say: let's do key key value labels because it was going to award custom fields. But now you know at least mark is a big proponent of key value labels going to the SM and then we would just leave it at that. And then we'll continue to have this conversation. And then we don't have to make that decision at least for one Mouse, and you know what will so actively argue and debate I think we should do that.

A

And you know one of my ass before you market is just define small perimeters I see in the handbook. As you know, product handbook biosea a clear definition. But but do you think that's a good next step so that we can say.

B

It, but you don't have to what I think that's expedient. There are two risks that I'd like to see addressed and we only have two more minutes. So maybe the first question is: do you mind going into the group conversation and we can skip that and watch it later and we can talk for another 30 minutes like and just try to wrap it up now, still some big unknowns that I'd love resolved. Okay,.

A

So why don't we? Why don't we agree on that decision for now, so that deciliters decision with that, like like the moment that we have to drop off because we're in this heated debate this moment? That's that that's a decision which we you know, okay,.

B

That's fair that sounds good or one I, don't want you changing your plans or that agree. My goal is to convince you not to berate you into doing it right. I! Don't want you doing this just because I clearly care about this. Never talking with you about giving in it's, not how well.

A

No I'm, definitely not giving you know, I mean for custom fields, I'm I, don't know if I'm giving in but I can like I see that the other side of the argument I think there's there's a stronger argument to be made, but I'm not definitely not giving in here. So that's.

C

A

Think anybody's.

C

Saying is is like let's, let's do some other, like really high value work that we all agree on. That needs to get done right.

A

C

Then continue this conversation.

A

So, let's, let's we can use I, can use the next thirty minutes to continue that conversation. Okay,.

B

So let me just make sure I just really understand those. So what you're saying is: okay keep al, you stuff is high value. Let's do it. It may or may not actually solve the custom, workflows challenge, but.

C

B

Some extent we're saying that's: okay, because we really want to focus on do Sam you're, not yet convinced that this does solve you some, but even if it doesn't it's still valuable. So who cares it's still valuable.

A

B

A

Have an NB.

B

C is defined. We can move forward exactly.

A

And it's it's a prior! It's a it's! A it's a cabinet! It's a high category! It's a great already item anyways. So the downside is that if it doesn't become DSM, then we've lost that that that's alright opportunity.

B

But that's: okay, that's not a good reason not to it's valuable, there's. Also some downside where it doesn't become even we're closed, but it's still valuable all on its own, because key value pairs are exactly.

C

A

B

Have the upside, where it might, in fact, do both of these things right.

A

B

A

B

Let's prioritize that exactly.

A

Multiply all those uncertainties together like in don't right now, in my mind, the worst case is you make me do this and you against my will, but that's a that's a probability and but it that's still. Okay, like the expected value of all that. That's still okay, because we still move forward in the grand scheme of things right so.

B

Right, the worst case is actually that we do nothing, because we just churn there.

A

You go so we believe I think we all believe in iteration. So let's find you're.

B

At least convinced that that's valuable great, so, let's move on then the the second thing was just maybe I should just retract it and back up, but I was I would like it if, whatever we're doing here, work towards VSM, because I agree that VSM is a great priority and I believe that, in terms of you know, really really high-level right. But if we just oh we've got customer floors versus we've got the SM I would rather deliver.

B

Feeis am because I, possibly via SEMS, are custom workflows, but custom workflows imply certain subtleties like oh it's about enforcing workflows, whereas you could do via some about enforcing anything and just say. Look knowledge.

A

Doesn't have to be enforced or closed, know.

B

Exactly but, but soon as you go down that like there are certain assumptions and I give you set a goal here: okay, by a certain term, you'll you'll start marching towards a certain thing. You've set a goal: the VSM you'll march, ever so slightly differently and and I, don't know exactly what choices we will make differently, but it's better to say, but goal is via sound.

B

Our goal is that aid not only we're, not gonna, just be viable this year we want to dominate and have like you know, if they're a gotten report again or a Forrester wave or whatever the that we would, you know be in the top right corner for VSM I, believe that we have that potential and I believe that it's important I believe that it actually is an evolution to a lot of things that folks are already dealing with and it solves sort of tons of problems. It solves like a project management problem.

B

It also solves like even a CIC, the pipeline kind of thing, but it also solves like potentially like Oh bringing like marketing into the value stream like okay, it's not just when you release it, but like there are five steps after you release it they're all still part of delivering value, so I really love focusing on the value stream. um So I absolutely believe that there is a world where labels are a key part of the value stream, but I'm, not it's not the only way and I'm not sure it's the best way.

B

I would love to have a strong vision for how we're gonna get to be us and what is really required and then sort of work backwards and be like. Does this small primitive get us there? It is a small, primitive sort of give us one step, but it's actually painted this in the corner and it does so I'll get a little bit more concrete. um I can easily imagine a world where you've got labels that you can apply to epic story issues and those labels.

B

You could define you know a stage or a stream or whatever the heck it is. You could define one of those labels and say: okay, great, like I, can put all my categories of labels in there. I could define an order to those labels.

B

I can maybe even have a you know some other way, although this now gets a little bit blurry, because part of the thing about value stream is like there's the horizontal stream and then there's there's also vertical sort of waste right or things that don't necessarily do Sal you, but stuff has to get done anyway.

B

I, don't know how labels works in sort of a two-dimensional thing, because labels are sort of by definition, one-dimensional, but we can do some kind of VSM where, like oh you've, got this one key and as you change the values it moves along, some stream.

B

So I could see that that being a pretty good value stream mapping tool and then you can go further and say well, let's automate some of these things where like when you deploy, will automatically have some automation that sets a value and then that will then trigger it to move along the thing and I'd love to get to a point.

B

Where then, the the value stream mapping isn't some person manually dragging things back and forth but you're like doesn't you could just actually sort of just watch it like you, create an issue and you just watch this thing move lets goes and then, of course, once you've done that, then you can add timing, calculations to it. You can start measuring. You know how long it there you can do your cycle time analytics on the entire cycle time or your value stream analytics on the entire value stream.

B

So I can imagine some world where that's that works, but there's a couple of caveats that I don't have answers for one. Is this vertical thing like if a big part of value stream is that you've got other activities that happen in a stage that are non value? They you don't move it between a state. How the hell do you capture that and I genuinely don't know? Maybe it's with additional labels. So, like you'll, have a label for the stage, then you have another label for different steps within that stage.

B

Maybe and then maybe each one of those stages has their own label, so they all have a unique set of things. I, don't know how do you enforce the things can only go in one direction. How do you enforce that? There's, like checks and balances, like it's great, to have automation that says when this is deployed, move it from one to the other?

B

But how do you make sure that well, but it can only be deployed when it's been approved and we have other mechanisms for that, but but I imagine people will put additional requirements on like something that's outside the system like this can only be approved when the press embargo has been relaxed, and then we do that some like well. What's, that is that time-based Reverend there's gonna, be all sorts of rules around there, but then get harder to layer on to labels.

B

So I could also imagine an alternate world where we say: throw away the label concept and just say that value stream define these stages and just define a bunch of rules and it's a lot more complicated, but the rules could be like if the status of the issue is this and the status of the merge request is this and the status of the deployment is this. Then it goes into this category and I.

B

Don't know if this is a good idea: I'm not composing it seriously at the moment, but is that what is if we have a different vision for vo sound, but the the debate that basically says depends on things that are far different than labels, then do we need to jump to that other thing and then that's what you work backwards? Is there what's the MVC? Okay?

B

What's the simplest of rules, maybe the simplest of rules is well, let's just depend on labels, because that's the thing we have, but the point is it's rule based and we're now defining the columns based on rules and etc.

B

So anyway, I don't want to go too much down solution, but I want to get kid to, though, is that if we, if we have a vision for what VSM looks like, then we can go back and say: okay, does this help us, or will this only go so far, and then are we stuck and that's the question I'd love to have a consistent, so.

A

Is that is that your contention that we are vision or BSM is not clear enough right now? Therefore, it's inhibiting some of the decisions currently well.

B

That's putting a very pointed thing: I, don't think I I, think I, don't know what the vision is and I don't know how well.

A

I can tell you that the vision right now when you say vision, I mean you keep using the word vision of what you've described to me is simply a design, and so.

C

A

A design right now for how the SM will work. It is definitely not to the degree as you specified it. So in your and I'll tell you what this division it design is. It's simply there's multiple stages, and you know the time between each and you calculate the average at you show it. You know like what you showed in the series d thing right.

A

So it's simply that, and so, if you, if your contention is that that is not sufficient to drive the decisions right now, I gladly, you know, do additional homework or designers customers and if you think, that's the right path to it, or maybe you think I should do that anyways, regardless I think.

B

Absolutely should do that um I think the reason I keep saying vision is to differentiate from you know, there's there's MVC right and maybe what you describe as an MVC, but probably frankly, that's no.

A

No, it's not! No! No, it's not a masuka's, it's so so much functionality beyond exactly.

B

So it's something beyond an MVC exactly.

A

And if you want to call that vision, that's sure I think. Obviously, in addition to the design it just as the customer probably I mean that's hope, that's what a vision means it's more than just a design of functionality. It's oh, why. Why is this? Why is this a good thing? What are your customers asking for? Guidance is. Why is this set us up for success?

A

So, of course, that and I think in the good lab spirit we we're transparent and we try to identify with some level of detail the future so that we can elicit feedback. So if that's, what you're saying I totally agree- and that could be a great next step, but I just wanted to clarify is that is that what you're saying so.

B

I think there's couple more.

A

B

I can look at here is one is there's like a short term, medium long term kind of thing, but maybe to bring it back. We also have these definitions of maturity, minimal, viable, complete and lovable, and it's really critical that we obviously define the minimal short term. You know design or whatever, really really well and in a lot of times. That's totally enough. We just say good.

B

Let's just do one thing at a time and we will learn as we go right, but sometimes it's really valuable to say, but here's what we expect or here's a potential world of this is what it looks like when it's one.

A

One possible future right: what.

B

Possible future, because that helps, you understand, totally agree the direction, etc. So I think what you've described is a medium-term future where.

A

And exactly it's a long time, because that does not have enough fidelity right.

B

And but, and so I don't know if this is exactly snaps to crit, but like maybe what you've described as the viable world right. This is viable there's, maybe some MVC first.

C

B

Viable and once we have these stages and you can measure that that's a viable feature, what's a look, what's it gonna look like before it's complete or loveable mm-hmm and I, don't and I, don't normally want to encourage people to spend too much time thinking about this stuff and get distracted by the other stuff cuz again, we're not gonna know once we try some right.

A

B

But you helped without me: I have an understanding of, but here's the longer-term vision of where we're going and that's why I use the word vision just about time to.

A

To imply there's some gray vs. absolutely.

B

Right this isn't, uh this is for sure, with the things it'll look like, but this is what it's got to look like before. It's like. What's the vision for when it's gonna be loveable, how this thing loveable, okay and then and again it's and it's not prescriptive. It's clearly gonna be fuzzy. It's gonna be wrong, but I want to have an understanding of so to get specific, you talked about kicking it's gonna, be stages and you're gonna measure.

B

My assumption, though, is that, with those stages, it's all manual like I'm manually, moving something I'm manually setting a stage. Well, that's great, but that's really not gonna, be in the lovable category. Even the complete category right whole point of why I'm excited by V asam is that we own the whole DevOps lifecycle, and so therefore we can actually just automate like. Why? Should anybody manually move something to say this is now then deployed? We know it's been deployed, it should be automatic, so automation is an important part before this is complete.

B

There may be other start and out, but but in the lovable bucket I would even go farther and say, like it'd, be awesome to detect that something was deployed, and then therefore it moves from one stage to the other. But can you imagine if I actually could take that block and just literally drag it to the column and then actually triggered the deploy like we actually had enough fidelity to say?

B

Oh, this is ready to move great move it to the next step and with one click, I set the status to say it's now deployed, but it actually was. It triggered the deploy and, and then it did, whatever else need to do. I don't know what it would take to get there and I don't want to answer what it would take to get there.

B

What I want to make sure, though, is is the direction that we have for the short term, a step on the way to the direction we have to the loveable long term or is it gonna paint us in a corner where we, we can't get back, that that's learned, it's a one leg or a to a door right and as long as it's a two-way door kind of thing, it's like. Oh, this is a step and we can evolve it and we can make labels work.

B

Somehow we can make stages, we can make workflows whatever it is. We can make it work somehow. Sometimes we know that it can be somehow but I feel like we can move on, but hey I want to see what that vision is that we understood that we I wanna, make sure we're on the same page but everybody our customers, whatever like when you paint that picture of a lovable version. Do people get and say yes, I absolutely wanna buy that that is amazing and then be like great now.

B

Here's the NBC and it is in that same direction. I just want to make sure it's not a direction. That's off on a tangent I, don't want to say, like yeah we're gonna do all this stuff and then six months later we're gonna get. That was a dead end and we end I mean if it turns out to happen to be a dead end and so be it. But if we know ahead of time it's a dead end. Let's not do the six months in the wrong direction, be like no here's this direction.

B

We need to get there and again once you've painted that vision. If we talk about this automation, it's two-way automation if we can apply that to labels awesome. But if we say you know what there's a better primitive there's, a better small primitive that we could do, that's something else that would actually get us there better faster. Then that's where, like great, let's do something else and labels that still might be valuable but like no longer related to the SM, in which case, maybe we told that you prioritize them again.

B

Let's ship them now and it's great: let's do them, but I would love to have this idea of where's VSM going what's the long term, lovable vision for via sound and then what's the MVC that gets us towards there. I.

C

Think my only concern with that approach is essentially like you painted ourselves into like a a lack of action or a lack of bias for action until we have like a lovable, a loveable design or vision, which goes against like the iteration value, because now you've linked iteration with like what the end the end goal is so I'm having a hard time like rationalizing those two things in my mind, right now, as you're talking yeah. No, that's a really really good.

B

Point- and we certainly have to make sure that we avoid that scenario. There's the request for a long term version should absolutely not in any way inhibit us shipping embassies, which is why I think Victor's great and saying like yeah, but let's just do label sets. We've got something to work on now. We will do that and it might work out it might not, but it's valuable and we will move forward. We will keep our velocity up and we will do that. So I obviously do not want the result of this to be.

B

Oh, we've got to think harder about it and then not ship. That's that's not right. Yeah, but I do want to start injecting a little bit more rigor into what we choose to invest in in what directions we go on and you know not sort of have like a Brownian motion like Oh any idea in our head. Let's just a small we keep reading on it, I'm not saying grace doing that, but I know we just we don't want to have undirected thing.

B

The point of having a direction is to align to that and say great. Let's, let's move forward until.

C

B

That is a good way to frame it. If we can't talk about it from a higher level and what the long term is it'll make the smaller term just much more efficient.

C

Yeah I think there is value to like asking this question each time. We want to do something right and this this is really going to impact plan the most like if any stage is going to impact plan in the primary reason, is because we're gonna compete against JIRA or collab matter version, one or whatever it is, and we're gonna have all these legacy. Enterprise customers that are used to doing things in that piece of software, and we have to take a hard look at things and understand how do we?

C

How do we service the needs of those customers as we get customers to move to JIRA? Obviously, JIRA provides first class customer workflow objects. They provide first-class custom fields now under the hood, I, don't know if those are actually like surface yes, small prutas or you know, polymorphism chunks of reasonable code or whatnot, but at least to the user. They're displayed as first-class objects, and so something else we should probably consider is what you know.

C

One of your arguments, which actually is like interesting- and this is why this conversation so difficult is because like there are, there are like amazing points on both sides and I'm, just like I I. Don't.

B

Know like I, don't know what the right answer is because.

C

Like you can you can do you read if we do everything that, like pictures proposed and customer feels like with labels like today, without the enforcement I guess but like then you could? You could just add that, like you just have it, let me see, but just say like they enforce, like a label ordering and you'd have it done. But then the question becomes like is that something like that's actually actually useable by a customer like?

C

Is that an intuitive enough process for a customer to Brok that and then to use it and then for enterprises to feel as robust enough to use as well and like I would probably argued like it's? The answer to that is no, so, but a really critical.

B

Part there, though great as soon as you get that answer, then you iterate and like let's say you do the MVC I'm, not saying you stop right. I'm saying you do label sets you don't do enforce me doing. These are the things and see how it works and then, when somebody says okay great, but this is really hard to use. But what you'll get is some portion of your folks and honestly, it might be as simple as like the intermediate to advanced users will figure it out and they will tell us about the capability.

B

But then nobody will be a new user who hasn't touched. This they'll just be confused and we'll have a huge problem with our onboarding, and then we can figure out how to do the onboarding, but if you at least make it really functional so that some people love it like that, like honestly see, I collab, CI llamo is really complicated. Yet people love it because it's incredibly powerful and expressive and they can they can do whatever they want. But it's not obvious. There's no, like GUI.

B

That tells you that go do this here, like we have a linter, but like it's not even real time, but don't you think about don't.

C

You think the reason to not those is a different Chris. No, no.

B

Like you're, not.

C

Gonna have a project made up going into a.

B

Mobile, so exactly so, here's an interesting twist on this right. One way to look at. Let's say you even do VSM and I'm not I'm. Just throwing this as an idea. I know that our ultimate customer is the project manager, but then also like the executive. Somebody's gonna want to be able to do this stuff, really easy at a really high level, but there's also a slice of it where, like even as a development team, we want to measure this stuff.

B

Like we've got a quality team where Mac is doing a ton of analytics to dive deep into how the development team is performing and doing measuring on listen. He if we gave him these small primitives, he would solve it. He would dive through all the whatever the headache it was figured out, use it in amazing ways, especially be given small primitives. If we could give him some timing on labels adding and deleted and whatever like, we would figure this stuff out, we would get some use.

B

It wouldn't necessarily be our ultimate persona, but we would get some use today and then we can extend to the ultimate persona. I. Don't disagree but I just feel, like smaller printers tend to they're, not great for onboarding they're, not great for the non-technical, but that's not even quite right, because, depending what the small primitive is, it might be a non-technical, primitive. But the point is that it's like they're saying you spent like we use markdown. We can throw that out. You know somebody was talking about the other day that, like.

C

Increased completely when they threw out markdown right.

B

Right so the whole thing is like we could get rid of markdown because that's better for me, but we've Thailand yeah, but developers love it and I want to at least have somebody love it. If you gave me label sets, I would love it. A ton of people that get loud would love it. A ton of some section of like the very technical project managers would love it, and then they give us some feedback on real usage and we would learn, and if we can do that faster, then we can say great now.

B

What do we need to do to make it easy? What do we need to do to really kill JIRA like because if we could even be like well we're the project management tool for really technical developers, but that's still a niche that's worth getting, and then we expand out to the next nation. Okay, with now.

A

Josh Miller I agree with your ideas in principle, but for the JIRA part I think this path is actually slowing us down in a chair, I agree but I think that's a good thing. That's fine, I'm, just I'm. Just commenting on that. Like very clearly your approach here, I think, is low risk.

A

It's it's not and I think it's it's not risky enough, I the concept of leverage right and then we're not attacking the problems specifically you're, allowing for multiple paths, as you explain it, and then we're not addressing the problems head-on and then, as argue that these problems had been manifested with labels already.

A

So to me, it's clear that the the risk analysis that you provide I think is not leads me to believe that this should be done as a first class abstraction, because the purported benefits of leverage as you described it are not sufficient, given the negatives that I've seen already so so that's why I agree in principle, but I disagree right this particular scenario. My.

B

Counter to that is that I think that I I understand that there are some complications with the use the UX, but I also believe that's why I started this little thing of saying we can still get to the same quality of UX through either direction, but don't.

A

Know that that's that's just not true right, like labels as a concept, if you want, if you, if you're, defining small primitives as something above the code, labels will always be labels, and you always have to expose that to a user and when you, when you're saying that that is always going to be additional complexity of the of the label object.

A

So you cannot just say we can just iterate and then, when the concept of, if you're overloading labels to mean something beyond just tagging, something by definition, that is a UX cost, we're maybe not a cost, but an additional thing that a user has to account for, and you cannot UX that away. That's my contention.

B

Maybe we need to dig in, but this is not the right time, but I think that there are ways you can do it I think the risk is more just that we stopped short, because we have something that's functional, and so then we don't make the easy to use. You actually don't do the rest of the stuff and that's totally a very good.

A

Thing yeah, the opportunity cost is we're. Not you know. Taking out here, I mean the risk is both ways right that what you illustrated is it's a risk. Oh we're, building the wrong thing. We can iterate rewarded for you, small critters, so and so forth. The dogmas of risk or the opportunity cost as it were, is we're not tackling the problems that are your solution. So.

B

Okay, now you're bring back here and so I want to close out one thing: I think from a UX perspective, final.

A

C

We should only have a second I have to drop. This has been awesome like you, should keep pushing through this together, but yeah I've got together, prepare for an interview. So I'll talk you later girls, yeah.

B

Just to close up these two specific things like I think from a UX perspective, not not close down mark I'll.

A

Let you have the last word for this video.

B

But specifically, we can continue to iterate on the UX. Just because we have a thing: that's functional and minimal doesn't mean that we then need to stop. We can stop if we choose that the continuing effort isn't worth but I think you can't address those things living in the past, where we've had a lot of contention and confusion, because we've overloaded things I, just I, believe in my heart that there is a way to solve those things without having to it like, oh and how you gonna throw it away.

B

We got to do it first class because that's the problem, but you just need to put the effort in to solve the problem, but then specifically to get to back to JIRA I. Think that there's also another failure mode sort of risk thing of like if we really want to just compete with JIRA. If that's the goal, then we end up like basically hitting feature parity and we just replace everything, but we just made JIRA 2.0 or we just made JIRA with a different brand and that's not the goal.

B

That's what I've been really careful not to say our vision is not to make JIRA. Our vision is to make project management and in particular what I would like to say and to formalize this somewhere but like if nothing else, I want to focus on project management for our like sweet spot of target user. First, like ideally like the conversational development, even button into that like let's make punch management, work, amazing for them, and then the folks that do lean and then agile and then do the legacy like we want to do all this stuff.

B

We know that we've got lots of customers that are doing safe and we know that there are lots of customers that are doing waterfall for that matter, and we eventually need to support them. But if we split them first, then we're gonna go down the wrong path, and what I want to do is make a really modern thing and then see where their deltas are I. Think that's really really critically important. So I'm, absolutely saying: let's go delay, go after JIRA, but let's not delay going after project management. It's just that.

B

I want to focus on project manager like even if we solve our own project management solve our. You know, solve conversational development projects going to solve mean type of project management which, in those worlds like constrain workflows, are a lot less important because you have more trust and more conversation. But what is the value that they really want out and it's like visibility and reporting and on measurements and all these other kinds of things, and we can do all that?

B

Let's do that first and then see you, okay, now what's missing, but also now really keep tying in the VSM I. Don't know exactly how this works, but I really I just had this belief that if we make via sound, we actually have an interesting way to like sounds like a new paradigm or whatever. But it's a different way of looking at project management, and if you start with the fee of salmon, that's a great now. How do we go down to levels? I?

B

Make project management work really well with VSM, so that we can deliver on this value stream? You might end up coming up with a completely different set of tools, and you can also win against JIRA by adopting, like sort of the next paradigm but like seeing like. Oh, like you know, majors really, amazing, as long as you're, only like myopic at this part of software development, but software elements.

B

Actually this and we've solved this whole thing and we've done it better and it's gonna be so amazing that you will gladly throw away that other tool, because we've got this amazing project management for vo sound and then have people, try it and be like ok. But there's this one little thing, that's still missing and be like. Ok. Is that really critical? Actually, no, it's not fine. This other stuff is worth it like.

B

I just know so many times in my past, where you present, like somebody, will ask for a bunch of things because that's what's usual and then you present them something else. That's so much better, but doesn't have that, like oh I want that, let's make the thing that is so amazing that they want that and they're easily willing to give up these other things that they used to have.

A

Do you think I'm gonna continue I'm, not gonna, argue anything. I just want to ask. What do you think you think the plan vision as it stands or, as maybe you haven't, had a lot of time to review it? Do you think we're we're not doing enough of that or we're just not doing that right now, it's just everything you've describes as far just just as just self-evaluation, so.

B

It's hard to say it might all be there I, don't think it's. Let me phrase it this way. I do not know if you like, when I just described as part of mine I, don't know if that's captured in the plan. Bitching I, don't know what your plan vision is and I don't know if it is.

A

Is that? Because you haven't had time to do the homework or haven't had time to put things in your calendar, or is that just purely that's?.

B

One thing would simply be that the like I, don't want to say, I, look at a plan vision I want to look at a vision for vo, sound and I want to have that be really clearly articulated. Okay and then a vision for project make.

A

Sure that that's not done yeah, so so you know that's my homework for sure. Okay, what I don't know if it is buried.

B

In the plan and like maybe it is no.

A

It's not it's not so I know. I asked that just too so I could have some action items. So thank you. Yeah.

B

So those would be this to specific or if I'd like I want. The plan is actually has two of the big of the four key things that we want to do this year. My project management in VSM and I would love to have a really compelling like this is what we're doing for that, and that's that's true for the other two areas as well. Right.

A

When we said like what we're doing is not detailed designs and guarantee we're gonna do this, but it's honestly.

B

I would love to even go further and be like it's worth it to spend some time like mocking up like not slow down delivery, but as a company I think these are one of the four top items right and so I want to say, like let's spend some time and paint a picture like this is look like. Do a mock-up flow like the same sort of fidelity that we did before but like? How does VSM look and let's paint that picture and get people.

A

Really excited other round of funding, and then we had to scramble and talk about this like victory. But.

B

Honestly, there's interesting parallel there, because the last the previous round of funding you know, was an October kind frame, and then he took me until February before I had a mock-up demo like this is what this is. Gonna look like right.

C

B

Then it took up until, like a couple of months ago, before we actually started to have then the real versions of those things so we're gonna. You know we're a little bit past February, but you know our funding announcement right. We talked about the vision, a really high level. This would be a perfect timing. Is that okay, but now this is what the fleshed out via Sam and project management, visualized, actually look like an CD and what.

A

I'm, getting from you is I, don't know you're saying this, but what am I? What I want to do is that or these key areas there should always be an ongoing, revamp and updating of these of these longer-term visions, because these are key strategic things. I, don't.

B

Know if they need to be like always revamp the reality is like. If you do a long term vision once and then you you start to have fidelity, I, don't know. If you then need to go back and updated me like okay, how that we've got this? Let's change, I.

A

Mean I mean a shipment, we should always keep like if the SM, like whatever the next thing, is maybe you're right, like it obviously I'm, not gonna. Do it every single all.

B

Right I see whatever these.

A

B

Yes, we'll have ongoing pushing yeah when we identify the next big item. That's gonna, exactly to complete or lovable like we should have a vision for how that thing's gonna get to completely lovable that that makes a lot of sense. Okay,.

A

Definitely get cracking on that so I think that should all feed into just ongoing discussion. So it's.

C

A good thing to have, regardless.

A

But it will continue to have us. Have these debates, which we should continue to record actually I.

B

Want to tie one thing back, please please, please, if nothing else too, one more thing over time is that there definitely is this risk of saying: okay, well, we're gonna go after long-term vision and if we can't do anything until that's defined, that's really horrible one of things. I love about small primatives, though, is that if I were to bet on you know whether a first-class thing versus a small primitive is more likely to solve this I'm gonna bet on the small, primitive and that's I, think I actually believe or I, don't know for sure.

B

If label sets are gonna help or be part of the VSM solution, but I would I'd say that more on that than a custom workflow thing, because the custom workflow thing. If we then are like oh, but it turns out, we need to add rules. Oh god, it's not brittle. It's gonna be really hard, whereas, like hey, there's this small little primitive of label sets it's the core of this thing.

B

But let's add another small, primitive about rules and automation, and we put those two things together and then boy and then the automation actually works for several other pieces, and it may not be as beautiful as if we had come up with a holistic design. But these smaller primitives like if we just had Lena sets of automation like oh, my god, what we could do with those things and then probably can also do VSM. And so, let's do it.

B

Even if it's a little uglier, the smaller primitives are just so much more leverageable and powerful and whatever so I. Just I would bat on that, which is why I still love the net result is that we do the label sets and then we move forward and hopefully they'll go tail. Alright,.

A

So that's it thanks. Michael.

B

A