GitLab Plan Stage, 28 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Value stream event analytics

Description

https://gitlab.com/groups/gitlab-org/-/epics/949

A

Awesome, okay, so we had a lot of chat about this, which is great and the the multiple flow thing you you talked about was great, so I I actually want to start specific, and then maybe we can come out broad I'm in the museum or I want to start specific I think we agree on a lot of large concepts, so I thought a lot about our existing designs and I didn't like it.

A

So that's why I wanted I came up with the different design and I wanted to share that with you and then maybe we can back up, and you can tell me why that's designers like that or whatever is.

B

A

Little design linked in the issue is at the bottom, exactly so 9.9 here right so previously you you, you probably saw a design which it's very based on workflows and whatnot, and so this is still somewhat based on workflows, but it's a little bit different, so this concept is pretty much the same way. We had a lot of good discussion about what cycle time is and to me, that's almost orthogonal to this discussion like I. Don't think we disagree anything there, but in any case whether we call it psycho time rally time.

A

We need some way to for the purpose of a product to just capture that information. So we need some start and some end right, and then we can define what those things are from a product perspective. It's it's actually pretty difficult to capture. Those I would argue for the lead time right, but any case we need like a start and an end. So that's what this first feature. Does it's really simple? So I don't claim.

A

This is a good feature, but I'm just building out my concept and then we can talk about what to ship first and so forth. But this concept is basically, you have any type of a start time and end time and you mark it simply with two labels. And then you say that any time you add this video on an issue. That's when you start counting and then start the timer as it were, and then any time you add this label complete.

A

Then you have an end time and then so you can calculate total cycle time on the average or any set of issues, and you know scope it.

A

So so, basically, this is just the very first first feature: it's pretty straightforward. You know so.

B

That's that well, it gives you the ability to capture that that's good, because it starts to give you the ability to capture some of the key metrics you're gonna need, and so getting this into place will give us the framework and infrastructure for the data we're gonna want to generate as we go exactly.

A

And so you'll notice, I purposely am NOT talking about stages here, so that is intentional. So there's no notion of stages here right is it. The notion is of the events right, what started what ends it and then the follow-up here is then this starts to get interesting, which is now instead, the or in addition to the start. In the end, you have additional events in between. So you again, the subject is or the from a product perspective.

A

The events are just gonna be adding labels right because that's probably the easiest thing to do, but you can see how this extends do something pretty arbitrary, which is great, which I'll get to it in a second I'm, not arbitrary, but general arbitrary, not in a positive sense, but you can see once you have those intermediate events, then you can make an assumption that there is an ordering on this event. So from a configuration perspective, the admin or the team lead or whatever, whoever cares you talk about multiple flows right so imagine this is.

A

This is one of many flows right and then they say that I impugn this ordering on the events, and if you had this ordering on the like on this case, it was sort of obvious starting that that's the ordering right, that's sort of obvious, but this one. It's if you think about it more specifically from a progress but that you have to have the user choose that ordering and the moment they choose that ordering the stages arise automatically, and he can you can think of them as stages.

A

But you can you don't have to think of them as stages. You can just think of them as the time periods in between these events and that's what exactly is captured here. The top line is still the end to end, but the ones in between are the the intermediate times, and then you can calculate statistics on that. What's interesting again from a product perspective and usually like when we discuss, we don't get too much detail in the product, but in this case I really want to start there, and then we can step back.

A

In this case, you can have all these edge cases like what if an issue starts and goes in the start and goes to complete and then bounces back into review, and like just does this crazy thing from a product perspective? I, don't care and I'm just gonna say as a first pass, have some algorithm to say you know in in the for all events that that was in started and then for all events in review, just aggregate all those and just calculate it right, yeah, yeah yeah.

A

So in theory, if people are doing this correctly, then these three boxes add up, because the sum of the average is the average of the sum right from from like University, not level now, but in practice. This may be not true, because if people are just doing some crazy things, looping things around so I'm just put.

B

In front, but in practice that will happen, things will go back and forth. I mean that's right, the reality, the reality is the world's messy and it will happen and exam it'll be one of those things that people will want to see, because this will be what people will track as an activity called rework exactly exactly the concept of that means. You know, I made a mistake or some sort of a defect or a problem occurred and I.

A

B

It over and so the idea, the concept we need to be at least thoughtful about how we build this. We can capture the idea that something that.

A

When there's loops or.

B

Whatever it moved back in the flow causing, because of the need to do some sort of rework of this.

A

A point that's a great point and that that feeds directly into the concept here in a couple of different screens, but just looking at this screen the way I've set it up. It doesn't lock that concept, because if we started the fact what you need to have a stage you need to define the stage and so on and so forth. Then it makes it really hard in the future, because then you have to define all those crazy loops and stuff.

A

But if we have the user-defined events, then the system can help you find those loops or the loops are, you know just arise automatically, um but the fact is, we don't have to have forced the user to define mutually exclusive stages, which I was getting really hung up on like like they don't have to assume that they just have to define events or tell the system that I care about these events and then kill that should tell you some. You know some information based on that.

A

So that's a very, very pressing point, and so, when you talk about, let's.

B

Go back to the so you have this idea of I'm just trying to understand, and maybe I'm too far, into implementation, we're calling these multiple label events and in the earlier issue. The first step in MVC is to label events.

B

A

You're, imagining.

B

So so let me just see if I'd say this out loud make see if it makes so what you're imagining is. Oh I'm gonna say this word over loading labels yep or define these sequences and flows right, and these will be special labels. I assume that they'll have some sort of special characteristic or criteria that says these are labels that were capturing key metrics on, because if you look at right, the use of get lab the way we use get lab today, we use labels for everything, I mean. Were you right.

A

So I glossed over this yeah yeah yeah.

B

Right we have, these are gonna, be a superset or a subset of label. That's a special label is.

A

That right yeah, so so so the short answer is yes and so I'll give you more context, which is. This is a debate that Mark one second I had been hung up for a long time and then- and one of the reasons is that we were debating about stages.

A

If you recall right and then we were saying like what stages with these things started and reviewing ut these weren't events in the past in the sense of labels, because labels are used in label lists and a workflow stages in issue boards, so we've always thought of labels as representing periods of time, because you're you're, the issue goes into that label stage or cirno type and then so I've been arguing with Markman set for a long time like no, no, no, we we need first-class workflow stages and then once we have first-class we're closed stages, then we can build dsm on top of that, and so, let's not you know, overload these labels.

A

That mark says no, no I, like small primitives, let's keep using events, so that argument is actually still ongoing technically, but I'm too actually trying to sidestep that argument and not even worry about it. So there's yeah aspects, one of them is the fact that is. We have key value labels that addresses some of this, and the second fact is I: don't actually care about workflow stages, anymore, I, just care about points in time and labels are already one way to do in points in time.

A

They might actually not be the one in the future right. We could invent new first-class events. Our question, then, are you imagining.

B

That all labels will capture the time data related to them.

A

Kendriya suit me, so that's an implementing T implementation detail and we actually have already done that. So that's actually great for some related, but not directly related work with system notes. So we already are capturing the fact that we have so every time you do this in the system. Right now, you can see how there's something stored here right, like maybe like a year ago. What was stored is just this sentence in a system note table and there's no associate with like the label idea and stuff like that.

A

What we did is that, and so, so that's why, if you look at some really old issues, it's really funky, if you close issue or it might create the project whatever, like the label, won't be rendered properly and people will complain like. Why is that the case? Don't you just query the label table just produces, and the answer is no, because we were just storing markdown and so now. What's happening is that, for example, this system note and other system notes that are not labels like a mouse, don't change.

A

They are still stored as just a system note like plain text, but this is actually stored like natively, meaning that if there's a database entry saying that this label was associated with this object at this particular time stamped, so we're already capturing that information and storing it as the first-class citizen and therefore this like like we could have like if we didn't have that we can build that. Obviously, but I'm. Just saying that, like half of the work has already been done to support this, that makes it easier exactly and to answer your original question.

A

How do we specify that I'm not saying that we go in to the label list and specify like from a design perspective you care about VSM, so you go there and you say: I want this label to mean this, so you go in here and you say that I already have a started label or I'm gonna create a label here to mean that it represents started and complete and so and so forth.

A

I, like this I like this, because this is consistent with the way a lot of times labels are being used exactly and so, but back to the earlier point that you know, I had the argument with with mark and and then there's a broader argument that we're overloading labels to mean too many things and it's confusing. The argument still stands that so ongoing debate that still UX problem in the lab about the fact that we're using labels for too many things, for example, custom fields right.

A

We don't have that yet do we use that a first-class citizen blah blah blah? But my point is that we can still proceed with labels because we can define other events in the future that don't use labels. Labels are just it. Maybe it's the first one but I'm just using it. As the first representative example of illustrate how the SM likely it will probably be the first feature. But if you or somebody else has a strong reason to not use labels, then this design still stands, and so that's what I was trying to divide you.

B

Know, to be honest with you, I tend to agree that we are overloading I if I had to side on the argument of being right.

A

B

However, given the fact that we have been using labels, the way we've been using labels and what they do for ice and then the data that you're the point that you made about how we've implemented capturing the time data already right here seems so.

A

Forward that is the argument with small primitives that we're formalizing on the product team that mark has really been pushing for it. So what I want to drive home here is the event part. This is where I was hung up earlier, where I didn't like this view, because of the assumption that teams work in this particular flow, and we said that what if they don't lose, this flow.

A

What if there's rework so my my concept here is perhaps there's a way to go beyond just the linear arity of this about this you know the lean manufacturing, blah blah blah, and then this concept here is that you have some notion of a timeline right and then you have events happening and then, if they vents, are that the fact that a person put this issue in review, the person put this issue in UAT, a security stakeholder st., came in and said this is violating security.

A

A business owner owner said, like we just came up with something you know awesome. Let's do some rework so there's all these events that goes on in the cycle, lifecycle of a feature being developed. That can happen at any time from all these personas and roles and they're just crazy, and they don't fit into this model, because you know a security. Concealer can come in really early on. A compliance stakeholder can come in really late and we know that you know we know the sort of the best practices.

A

The shift left like everything should happen earlier and if all the like the security stakeholder comes in at the back at the end, and you do security at the end, because you don't have you know DAST and SAS, and then everything goes to hell at the end and it forces all that. Rework that's a really bad anti-pattern. But how does get lab? Tell you that right? How does the elapsed surface that information? And so this visualization and concept, is precisely to do that?

A

It's to say there is so many events of the type compliance review and they all happen at the end of this timeline and then there's this huge scatter plot of that and then there's a correlation which I'm not showing here precisely. But maybe it shows that because, due to that high statistical nature of compliance events happening toward the end, your cycle time is really high and so give that should tell you that and suggest. Like compliance, you should you know, shift left.

A

So that's exactly what this concept is trying to try to bring out and that's my amazing idea that I don't know if it's amazing so I think.

B

I think it'll be an interesting view to see what comes out of it. That's maybe the thing that I'm looking at the other, the the multiple event, labels and and I think the view that people are gonna want in order to drive improvement order, understand their process, one of the ways of slicing that bar chart. You know which, looking at it over a month over month over month, it is going to be able to highlight which of those label.

B

Events right is consuming the most amount of time which one of those is the weakest link right and if you can, and so rather than listing it as started in review, you eighty complete in the kind of the chronological view goat me reading from bottom to top the way they're stacked right now, if if they were stacked, another way in which the longest one was at the bottom right in that, if I look at this and whichever one is at the bottom, that's my long tenth in the pole or long pole in the tent right, where that I'm glad this is recorded, but that's the long tent in the pole that I should work on working on.

B

All of you know if I'm gonna have the biggest bang for the buck, it's there and- and that was the learnings from the goal and frankly, from the Phoenix project. Was you know in trying to go faster? You can only go as fast as your slowest.

A

B

Bottleneck yet part right and so being able to highlight the question that people will want to know is: this is all nice and pretty, but where should I focus or where should I look to try to improve my cycle time right right this? This is the dashboard that says. Okay.

B

This tells me what my cycle tightness, but it doesn't tell me it doesn't give me recommendations or clues, yet it's close to it, but I, don't think it gives me the clues yet as to what to improve we're, getting really close to that that which is really the Holy Grail here, I totally.

A

Agree I'm clicking around not because I'm ignoring you but I'm frantically go find an older market that does that serves exactly what you're saying. Yeah clearly cannot find it. Okay, I'm gonna, stop so, but I I hear what you're saying so. What I'm getting out of this conversation is that this is not too spectacular, which is which is that what I expected, because I think I honestly think this is the future and I think this is a stepping stone to it.

A

But what I like about what I'm proposing right now is that, instead of forcing people to use stages and define stages and then just like just slightly, it's like a you know like a magic trick, just have them blow on your beds. Instead, it doesn't block us from a this and we don't keep going.

B

On this, one go go ahead, good, the scatterplot one works to accept your horizontal axis is not the time line. It's the duration, yeah.

A

It's that's what it's it's supposed to be here like it's. This is supposed to indicate that this, like on the average it like, maybe there's a total here, and so this is not a time like this is representing the 14 days here, and it's supposed to represent that there's five five issues, issues in this time period or in this statistic, population and then of those five issues. The first one landed here in review it the first one landed here in uet in the this one and then so and so forth.

A

So the average is somewhere here. The average is somewhere here in the average is somewhere here. The.

B

The challenge with this view is because it's cute because it implies cumulative nature right, it's cumulative. It implies that the total project, time, if I, look at the rightmost issue, the dot at the furthest right at the bottom, on complete that the the longest issue to 14 days, the shortest issue took oh right right right well days. In fact, what this view would be more interesting.

A

This is just an incorrect view. I think you're right like because this come. This is a cumulative view which doesn't make sense because it's that's.

B

Right if this wasn't cumulative yeah, if this showed- and the word started, is confusing, because we've used that in the concept of of a right of a labeled F in defining this concept. So you know it's it's really about. How long did an issue spend in any ride.

A

Right April.

B

States, that's actually interesting, yeah and Beckett, and that gets to so yeah. That's why yeah.

A

No no I know I do know, I started. Let me do mine 30 seconds. This doesn't make sense, so I take back what I said, because these are like cumulative. That's the problem, I think we're I, think I'm hearing you, which are agree with. So these are label events, so that the the time in which UAT took occurred at this moment in time so started is zero time and then everything is referenced as zero time was started, and so these are cumulative in the sense that it happens at started.

A

Plus this amount of time and so from from an event perspective. This view makes sense, because you can see that the completed actions took later are very, are congregated toward later in the lifecycle. I still totally agree with you that this is not very intuitive or maybe a more advanced user would use this, and this is the more direct thing, because most humans have a sense that these are still mutually exclusive stages right and you want to optimize for that and it's the lean manufacturing thing and so on so forth.

A

But but but again, my point being. Is that I? Don't like how it's boxes is in because it's going back to the point where it's for well I mean this is where, let's, let's, let's talk about broad lean and I, think this is a good point to do that, which is we've always been talking about in some yeah. This is the fundamental question to have so: let's switch there, we've always been talking about.

A

Like we've seen, customers go from like not using stages at all or in the past its waterfall, then they use like stages right in review and blah blah blah, and then some people are just doing hardcore Kanban, where there's no stages at all and then they're just you know, shipping software, and so my question to you is that is.

A

Why is this view still relevant in like 5-10 years, when most people don't really care about individual stages and optimizing them? They just care about ripping the most important thing off the list and then having people hyper collaborate and they're measuring all the time together, but they don't care about the individual stages because they don't exist. So let me start there and then maybe understand what I'm missing if I guess.

B

The question is to how likely is it that large enterprise customers are going to adopt the a we are going to get to that level of maturity where they, okay.

A

B

A set of defined steps or that they don't define a flow I I, was in a webinar, yes Monday with CTO at the air force and a chief of security at Capital, One hmm and and and the common theme, and these are people that are driving DevOps transformations and digital transformations in our organizations. And you know: Capital, One, they're, very pretty pretty darn advanced yeah yeah and the consistent.

B

There was a consistent theme in the in that panel discussion about having a defined kind of set of ways of tools and processes that they expect people to work in, because they expect that consistency. And if, if you're running an organization with ten thousand developers, you know you either there's a degree of accountability that you have to be able to demonstrate from compliance and flow and din right, making sure the right thing. The right evaluations and tests. Everything else are kind of are being applied to the changes that are going, live and I.

B

Think that the the that there's a conflict between this idea that we're going to just rip stuff off of the backlog and we'll work on the most important ship and ship and ship as fast as we possibly can, which is what we try to do here. But I, don't know if in a large financial services or a regulated industry, or you know, organization, that they've got that there have to impose some structure on if that allows supply. So so.

A

You don't think like it's realistic, like there's, always gonna be structure, another way to put it like, even if this promise of DevOps transformation we keep going ten years down the road. There's always gonna be structure because there's always gonna be regulatory things. There's always gonna be best mitigation. There's always gonna be a chief risk officer at a company that says, like you, always need to check bla, bla bla and then so. This will always be needed. I guess is the point, and then it's a matter of how you may be overlaid this.

A

On top of this, make this a little bit smarter or you volved this. So you can see that we work like I talked about earlier. I I think that the the so.

B

I think the premise that the the the defined set of flows or activities in a development lifecycle and the way people work right, somehow going to go away right, I think that premise. While it may be true in some organizations, you know there will be some examples of that. Where that happens, where people are building fairly, you know customer centric customer facing web properties that aren't financially sensitive, that aren't that are in a regulated industry.

B

I think there will be examples of that where people will do that and will operate a model, that's very dynamic and very fluid. Totally gay I think we are at some level an example of that you know we're leaning in that direction. Right now, I think there will always be, though, for for a long time always is probably the wrong word, but for a long time larger or the purpose.

A

Of business for the preference.

B

Yeah fruit for the purposes of the next five years. Next, ten years, yeah yeah, that means gonna exist and I and I believe that the people that are going to want to buy a piece of technology to help them be more effective, are going to look for something that allows them and enables them like find what their expected work activity is. Yeah.

A

B

To measure and to get feedback as to well how's it going right and and if they want, if and I think they will always have the option of well I. Don't want to do that. I'm gonna, ignore that I'm gonna do something. Do it a different way? That'll always exist sort of thing. If we don't have it as a capability, if we just say well, you all need to get to be fluid and flexible, and then then you'll. Then this will all work for you right, I, don't think!

B

That's a good business model for us right.

A

Right I agree with that: okay, no, no, so that's really helped I I! Think that's what I suspected I'm really happy that that we're not boxing ourselves or there's another reason where I go I, don't like the workflow stages, because when I started, designing workflow stages and thinking about whether we use workflow stages or labels to represent those we're pool stages that we have to figure out like to think about the neck, wonder what do we do next? So it's gotta be automation.

A

It's got a time with merge, request and then I started like going crazy, because then you have to what? What are those events or what are those stages? And that's like do. We add merge request to issue boards, how about pipelines, and so that gets really really messy. When you start with stages and saying the stages must be an issue board, I used to think that, let's start with an issue board, that's an awesome idea.

A

I still think it is, and I'll show you a mock-up in a second, but that was actually tying me down and boxing me in from leveraging other parts of your lab, which we must do and so the the concept. So what I'm hearing is that we should build this on the Left. Obviously, the the the dots are great. Probably we don't need to build that. That's a nice to have it's like something, though. Well, the dots are easy. I think the hard part on the left is.

B

Your three arrows at the top right.

A

Well, what do you mean them in what sense well.

B

You know so frankly, the data that shows up in the stacked bar chart right, you're gonna. You have that I mean frankly, you could probably create the stacked bar chart today, yeah yeah.

A

Yeah, we essentially good.

B

I think we're the harder part is defining what that defines. Sequence of I feel yeah lynnie is if someone wants to define a linear flow that it goes from started to in review, to uit to complete, say those. Those are the four steps with the very transitions.

B

Then then, I think the question then is is how do we both define that with it with labels that labels must go into this sequence ABCDE? Is it one way? Does it you know if they go in the opposite order or a floppy, a back stream? Do we you know? How do we got any I think the challenge that we're facing and it's I, don't think it's insurmountable I think but but I think the hard part is in and I'm drawing on my screen, you're not seeing it, but most those for those three right.

B

A

Saying it's a challenge because conceptually it's hard to map to user expectation is that is that, because, like technical design, perspective I, think it's straightforward, but I would agree that it's we design.

B

It but maybe nobody.

A

Uses it and it sucks I, think.

B

It's anticipating the in how we implement that and how we anticipate it. Well, how is that going to work, and how are we going to? Is that going to be something that a a you know? Who will have what what permission level will someone have to have and.

A

Right I feel everything XD fluence.

B

How are we gonna, you know I, think, there's details in that that we have to think through that, let's assume that you're, a big financial services customer you write.

A

B

You know it starts with the G right. Let's just assume that you in your large organization, you want steps way through me in that order. Is the flow you're defined your 10,000 developers need to you know all your work s go through this, those those three letters: five lettered steps, yep, okay, so on the CIO I decided that yep.

B

It means that you know Jimmy. The developer doesn't get to willy-nilly reorder that or change it right, and so it's a question of of how are we going to implement that that rule those business rules that someone wants to impose alright.

A

B

A

B

Traditionally, the falah, our philosophy, has been not to let not to have the tool in the place of imposing business rules. Well,.

A

uh Do you mean that constraint, so we definitely business rules about or maybe when you say business rules you mean like I, think we had this like.

B

Example would be a nice work, clothes and force.

A

Work and I think that was the bad word that we've been saying that we wanted to avoid. Is that.

B

Yeah but uh but I think that the the culturally we've tended to be more from a philosophical approach to the way we build the product to be much more flexible and to give push and empower develop. I, don't.

A

Not bro I, don't think I think that's more of a like a mistake of us not being good enough in their product. I. Don't think that was intentional philosophy. I think it's just like. Oh, it's really powerful. You can do all these things with projects and groups and like customers are complaining that it's so difficult is too powerful. It's not so so I, don't think that was intentional. I think I think it's just. We were because we've been the philosophy. I don't think is about necessarily about openness. It's about.

A

We want to cover more scope and cover more use cases, so people been chasing a lot of functionality and and breadth and then really hammered down on the depth, and so I would classify the business rules and maybe a little bit more helping people go a certain direction in terms of.

B

And maybe that's the way we position this as this is we're. Establishing a set of business rules, set the fall of work in this group. This project right.

A

B

Yes, yes, yes and.

A

B

The but you got to understand also that people will add F to it. They will add b2 to it because they're trying to improve something. You know you know they'll insert things so it's it's gonna, be dynamic and will change, but it's gonna change in a slower pace. I think, then you know it'll change.

A

And so that's one of the reasons: I love the event approach because yeah, it's flexible, it's flexible, it's extensible! You can build those controls, constraints enforcement- whatever you want to call on top of that, but we don't have to worry about like when I was thinking about stages and I'm like oh, then we have to figure out what these stages are. You can't have like.

A

You have sub stages like you have stages at the group level, and then at the project level you can overload those stages and add more or subtract and it was getting really messy, and so with events you just have a base set of events. You can collect and track those events. You can have external controls about how certain issues can float into certain events, but that can it's a totally separate problem to be solved and everything that you said we can iterate on top of, but it doesn't fundamentally constrain it.

A

So that's why I like the event approach, I mean dude, so you.

B

Said something I'd like to riff on, please I think it's perfectly flexes design is perfectly a appropriate board, so I think you've got it covered sub stages.

A

Right so so sub stage is how I would think about. That is that they, let's use your example right, see I'm mr. or mrs. CIO says, there's these five stages, because he or she wants visibility for all projects and issues and then an individual team.

A

They want because there's more regulation, their review stage is broken down into three additional sub stages with you know, like code review, regulatory review, security review and then so they would just have those three sub events, but the moment that they enter that review stage at the high level at stay there and then at the sub level or in that project level. It goes into additional stages, but it did not exit the review stage or did not go into the next stage at the high level.

A

So then it still works because they're all you're tracking is events, there's no notion of being inside a stage. Actually like your your your code, abstraction logic, your business logic. Using your terms, business rules will take the events and then manage it as it needed on on the feature set that it needs to be so it doesn't at the base level. It doesn't matter. So that's a great example of how this could be leveraged. Well,.

B

And it allow it allows, for you, know, shifting left and parallelism as well exactly.

A

That was the original concept right about about what what I said like we have an organization where you're doing your regulatory review in the stage that you've defined it as a label, but in the future. This is exactly what this issue is: let's have an event, a customizable event where you associate a persona and maybe like some metadata. Well, maybe just the persona right or maybe, hopefully, maybe that we have roles in the future and then one of those roles is going to be compliance, stakeholder right or compliance officer of compliance analysis.

A

And then you have that compliance in that analyst just type comments in the issue, and then you log that and then that that is an event itself that you've customized and you towed to the system that you care about and then- and so that's that's what's that here. Well, what is that there and then that won't appear in this scatterplot. So, even though the compliance compliance analyst logs comments that event is not a staged in itself, it never doesn't have to be staged.

A

But having that information, ensuring that the compliance and analyst was always doing it at the end, that's super valuable information. Maybe it's more of like a really you know edge feature, but it's something that we could build and I think what people could live. This.

B

Parent-Child idea of a hierarchy of labels that could correspond to this. This flow right is interesting, and it's interesting because I think it would open the door for us to really talk about working concurrently and move away from linear right.

A

Exactly that's that that's why, when I was slacking, you and William I I was like I was frustrated because, like this, this word concurrent DevOps has been in the back of my brain forever and then we've always talked about these linear workflows and then in seeing how good lab operates. We clearly don't operate like this and there's this huge dissonance in my brain and so this. This is precisely how this came up and I wanted to solve it. I went like this doesn't make sense and I went in one huge direction.

A

I said: let's throw away linearity and let's just do concurrency and then and then, like William, said no, no, no Victor, like concurrency, doesn't mean throw waste. What he didn't say that he just reminded me: concurrency was hammering on the point that in get lab you can everybody can type on an issue and anytime they want. So that opened the door to me a little bit, and then you reminded me like no, no Victor, we still need flows and as I'm, trying to marry the two concepts here and so no no I'm completely.

B

With you, but the potential you said some work, so if I think of this at the kind of the whole program organization level, let's then define a set of here. The here are the looks right. You know the steps you need to do right, that's one, that's one layer of it, but when I think about the compliance activity and the compliance work right right on if there were five different.

B

So if I'm the so imagine for a moment that one of us is the leader responsible for compliance activity in the organization right, we and our team are going to define five different activities that go into doing compliance. Now, we're not saying we're gonna, do compliance at the end right might view compliance work really early, and what does that mean exactly.

A

Yep yep I hear like what well to me what that means. Is that it's flexible, because you can do compliance. You can overlay that on the flow you can have multiple flows. Like you mentioned earlier, you can have compliance as a sub float here. It can even be a separate from a business perspective. It can be. You can manage.

B

Us every separate.

A

Business process, which is also a good thing right, because you could have been yeah.

B

A

One flow and then you can have your compliance team say you know they must do it on a different cadence. It could be not even snapped to the issue cadence, but it could be like you know, every Monday. They have to look at all issues and do something I don't know if that even makes sense, but it does know it does it.

B

Completely does and what I'm, what I'm getting to, in my mind, is saying. Look if, if I have compliance steps, one two, three four and five just to be not just not to confuse yourselves with the great Yee sequence and let's say II- was the compliance step or the compliance event right. He is really not an event. The events are 1 2, 3, 4, & 5, so 1, e2, e3, e4 and e5 are the events that happen and the cumulative activity of those events.

B

The cumulative metrics of those events would add up to what the total for II was. You may never really do be. You know really you're gonna be 1 e, 2 e 3, E, 4, T, 5, and really. What you've done, then, is what you could be doing is establishing a parent-child relationship between labels right right that the child labels are the actual events or the actual activities that someone would do and is that.

A

B

A

That no I just wanted to make sure I'm capturing your concept here in the screen, so that we're in the same page is that, like sort of when you're thinking about here yeah, let me let me make a big screen. No.

B

A

B

No, it's fine yeah I. Do this I do the exactly the same. I I do exactly the same thing in the end up document, so so different works.

A

This breaks down into these four events as you're saying our condom.

A

B

So yeah, so if compliance was actually those things right, right, Ahmet imagine a scenario where and actually in this scenario, you're a one start and stop of e1 adds in to start and stop of compliance start and stop of me to start, and it may not be and I. It may not be that me one. Each leads to e2 leads to e3 elites before those are just the events that happen. I see what you're saying right and.

A

B

The arrows right.

A

I see what you're saying because, like a three, these might be just the required things that need to be done by the traffic people and they can be done right.

B

Right and even one might happen during the business proposal before development even started, I see what you're saying yeah right so they're, not just eight more of its approvals flow is what you're saying you know: I don't know. If I want to call it an approval flow, it could be. Maybe you could read it as approval flow, but you know and I think of you think of QA. It's.

A

A blocking gating flow right like like it, could be you're saying that these events must occur before anything or maybe it just must be done before the whole thing is shipped to production. Thank you.

B

This this is this: is the business rule challenge of how do people want to implement this and what I? What I'm getting to is is the idea of defying the second layer of sub sub labels or sub stages right gets into the where they actually, events are because the event isn't development. The event isn't compliance right, right, vents are the details that are are deeper into that exactly and and I'm. Just we for sake of argument. Just let's change this.

B

You can change those E's to C 1, C 2, so that way, at least as maps above it.

B

And similarly, you could have d1 d2 d3 d4.

A

And and if Mayhew.

B

And you could have the similar subsets, but then then the deal would be. Is that what you'd really be then tracking and managing would be and visualize? It would be a rollup at the development, compliance, UAT production level or a more granular view that illustrates of these specific activities or events, events or activities of.

B

Where of what they're what's happening with them? Yep so anyway, and in there- and this is where an organization a business may say- I expect this to happen in from left to right in a order they might want to impose that rule in their organization. They might say: c4 must be complete before we go to UAT right before proceeding. You know this is where being able to define the business rules around. These events is going to we're. Gonna need feedback from the community, but I think the business rules will exist at this layer. More secure.

A

B

A

We're saying so so to me, the underlying mechanism should both be events but I think what you're arguing is that they're from a user perspective, there's a great future here to have like at least to like two concepts. One is the flow concept, one is it events concept, and so that may be perhaps like the or yeah like an event concept for the business rules. Like you said, and then this is maybe this is more of like a product development driven concept, and then this is maybe, like a you know.

A

What's a really broad word, compliance is the right word, but like safety or like risk mitigation response, you.

B

Think the reason that the lifecycle, the word lifecycle, is you is applied to software development or any of these is, is its applying and implying a set of rules or processes that expect people to follow. So that way, you know as a as a developer as a tester as a project manager of product manager. You know what you need to do right to comply to make it to win the organization to go from idea to production, otherwise, there's it's random, but.

A

Back to back to your original point like there needs to be some structure, it's it's how we provide that structure in the midst of this chaos right, yeah, yeah,.

B

Because I think I think this this layer, the second layer, is rare. There will be very keen interest on what are the rule and I think it's the same as the top I think I think. If we think about the first layer of this right with the same constructive, is there a? Is there a rule about linearity? That right must go to C must go to UAT? Is there a rule about you know tracking things moving, you know in the opposite direction right? Is there a rule about.

B

Skip about things being skipped right and and I think if we get that right, then if you say: okay well, my my compliance.

B

Sub-Steps, our c1 to c4 the same kind of rules could apply and in fact, once you get to that lower level. Now, that's where you'll have some issues, though, because if you establish a set of rules at the parent level, when you get to the child level, can you break those rules? Could you start compliance before development before, like.

A

I I think we can avoid like this is getting really into details in the weeds here, but like whether it's one or two levels or whatever like like when we design, if we do decide from a from a user perspective that there's two levels, even the design I wouldn't like have it be first class. Like the background shouldn't know about two levels: there should be n levels, and my point being is that you can think of these as stages, but there's still events, because development stage is really just the development start.

A

The event and the development end about the same compliance. So the way I think well, but.

B

Here's the question is is is how we support it's that second, it's the arrow between development ends and compliance starts. Mm-Hmm, it's it's! It's is there a rule of business rule on that transition?

B

Yes, and how do you give the user the ability to enforce the rules on that arrow? That's second arrow mm-hmm.

A

I agree, I, agree, and so so in the original model. This is one event right. If this is one event, then that's sort of by default, that that is the business roads. It's understood to be the business rule, because you can enforce that right. In this case, it's I don't know. I made me I think that back so this is thank you for today today,.

B

And get lab that's the way it works, because you're moving a list, you're moving an issue from a lip from a label list.

A

Right, yeah, but but we're like yeah yeah, maybe we're not the same page anywhere, because that is true today, but there's no enforcement on that. So right.

B

So so I mean it's it's by default and you have no other well, you do have options, I mean you can go around the board. The way the board yeah.

A

Exactly so, there's a lot there right, so so that that's what I'm saying like that, the baseline structures there, but the enforcement mechanism is not clear at all. Look, you don't have one and we build it and it gets into.

B

The, how do you define what that expected sequences.

B

And and I think the other question is: is you know the other way to look the business rules? You have to do compliance every project, it doesn't have to happen after developments done. It should happen while developments happening so there's this idea of it must be done or it's optional right, right, right right. Exactly! Oh now, I've got a headache from glad when we recorded my headache I'm glad to join your headache. So cuz I can see.

A

There's a lot here, but I think we there's more than enough to start so that that's what I'm excited about and what I wanted to bring full circle is like. We talked about a lot of those crazy events, but what am I excited about? Is that because of it, if it is indeed an event-driven system, it doesn't have to be labels right. We we start talking about labels up now.

A

We're we're deep into events, and events are just any just thing that happened and they could be associated with any object and we can invent objects and we can associate events with people which is a concept in a lab which is great and then I think this would be exciting as something we build very early here with just associative board with that concept, and so the Association is simply.

A

If you have an issue board with these labels already up as lists, then with one click, you can configure this screen because you have tissue board already created and associated with it, and so that you had this type of UI on top of an issue board off the bat. So that's sort of like the obvious thing we can build.

A

You know within a couple of months, but what we talked about for the past you know 30 minutes will keep us busy for like at least a year, but if we just execute on this concept with labels, integrating with the board I think we'll be in very good shape already and then yeah I think it.

B

Takes us a cup, it takes us clearly a few steps down the path and I think where we're headed is likely. It's likely to get to the place where we have to have to consider this hierarchy idea, but.

A

Right exactly exactly I like yeah, don't the conversation I got up today is connecting those events into a hierarchy and making those connections. I. Think that's! That's really well.

B

And it's it's understanding, optionality that some businesses, some organizations, are going to insist on the ability to impose structure right otherwise,.

A

B

Lot and we have to be able to serve both well.

A

Like we served the former, we should be able to service their gladder correct, yeah.

B

The tougher one is serving the one that wants to impose structure, yeah.

A

Well, I guess doing it in a way that doesn't make it alienating to the ladder and having sensible defaults and all that so that that is not easy either. Okay, yeah! No! No thank you. First time, John! Oh this.

B

Is awesome this.

A

One absolutely.

B

Fantastic yeah, no, no, and thank you for the feedback on the MQ work. I'm excited about. We can't talk about, but your feedback and your contributions are excited, yeah, yeah, exciting and it's I'm looking forward to when when it gets published. So definitely yeah. Well, one last thing: since we are recording this and you're gonna put it on YouTube on guard on Gartner's pure insights, if anyone's following along has following along this long, your contributions inputs into Gartner, pure insights and absolutely fantastic.

B

We've got over 30 different reviews of get labs, says 32 different reviews are on our agile planning tools on get labs. So ok.

A

I did absolutely.

B

A

Peer insights is the thing that Gardner puts together as a let me share here. Please. Let me share my screen. I'll share my screen.

B

I'll show you I think it's absolutely fantastic. It's one of the coolest things that I've seen happen with what we do a get. Laugh. You see my screen. I do so. If you go to Gartner pure insights, garner got comps.

A

I've seen this page, like Joyce, has probably seen this a to me phone.

B

Yeah, but so here's a type in get lab now, we've been up there from application release orchestration for a while. So it's right.

A

Probably long yeah.

B

There's 128 people have have looked at, get lab for release, orchestration, mmm-hmm.

A

B

With a overall combined rating of what is for point something can't tell from here, but you know, we were customers, choice for for release, orchestration right if I go back and I search for enterprise, agile planning tools, which is what we are right, they've 32 reviews they just started this yeah. It's.

A

A long term, four months ago,.

B

It says 31 verified reviews, okay,.

A

B

Many of them are five-star reviews we're all rating. If we go to the total space of this, here's a little get lab with a 4.0.

A

B

That's let's: let's sort, let's sort this list just to make it clear: okay, so there's there there's a couple of them.

A

That have somewhere.

B

A

Just say they're biased because they only have nine or less reviews. So it's a statistical yeah at the top of.

B

Those products with more than 30 reviews, we are.

A

B

There's target process with a 4.4 yeah.

A

B

A

This is just this is not Gardner. This is just like this is Pico to just go slow off the street right, wow they're, not it's not Joe Schmo off the street users.

B

In the using it lab, these are people. These are the real.

A

B

Is what you're saying yeah this is really cool I mean for me. So even if we could say people with ten more than ten reviews, I mean right right. Oh so, yeah no.

A

B

A

Did not I did not know that, like okay, so yeah, even before waiting from you know the experts at Gartner themselves. These are like you said that the the community that the actual users are rating us hi, I love it, which.

B

Is fantastic, amazingly awesome and I'm? Sorry.

A

I'm so excited to be part of this, and it's.

B

It's fun to watch. I watched I watched this, probably every at least a couple of times a week. I take a lot of it. There's new reviews coming in every other day. It's not surprising, I did not know it was so active yeah.

B

So so there I've added that to our Thank.

A

You Johnny, that's that's the best part of today. Thank you have a great rest of that. You.