alesdonoso

In 2019 we began to create a software (SaaS) to improve the software development cycle and make teams of engineers and managers have more visibility over the entire workflow.

Our vision was to bring the reality of the state of the development cycle closer to teams so that they had better data and increased their success in decision-making.

We were having relative success (not in revenue, but in clients), companies of all kinds were using our solution, including companies that are known to all.

In 2020, in the midst of the covid crisis, we were forced to paralyze the project due to lack of funding.

Now we have thought that it may make sense to sell the software to some company or team that has a real need to improve their development processes.

We are selling our product through MicroAcquire. Does anyone have experience selling startups? I am delighted to hear from you.

Hi mrits! thanks your for your reply :)

That's true. The point w/ Code Churn is to have an approximation to know when there has been more flow of changes in a specific repository.

Hi royosherove! Very interesting GOTO! I think these metrics you are talking about are really interesting.

At minute 30:13 you talk about those indicators and put some examples at the blackboard, I find most of them very interesting but for "Critical Security Issues" I'm really wondering how can you differentiate between PRs that are fixing things that PRs that are just implementing new features?

Thanks for reply :)

Hi there lovich and thanks you for your reply!

You might be right since too many it managers work with OKRs so they don't need as a the first instance tool a git analytics one. In your case, it makes sense to have a tool like Scope "as a secondary set of measures" if everything is going well in your company! That's the point overall :)

However, our tool involves engineers "gamifying" their processes so what we get is more motivated engineers, better team communication, company climate and culture.

For managers, all data behind SCMs could be easily tracked so we make life easier! For non-tech profiles and remote teammates asking for metrics, it's worth also!

Which kind of business are we talking about? SaaS, e-commerce,...?

Hi again knight and thanks for your response!

Sorry if I misinterpreted you at some point. Of course, I fit your criticisms constructively and I have always tried to answer your questions not with the aim of saying "this is what you get, you draw the conclusions".

I hope my answer is more conciliatory and you can understand our value proposition! :)

First of all, Scope's sense is to help IT Managers have data. What kind of data?

1. Know the workflow of engineers: frequency of commits, pull-requests and revisions. With this data, we can know exactly the productivity peaks, the days where you work the most and the time slot where you are most productive.

2. Know the duration of the tasks: with a historical data, software factories can adjust budgets better and have a better idea of how long it can take them to finish a specific project for a client. We can see two things: the duration of tasks at the project level and at the engineer level. We help to know the evolution of time by days, weeks and months on both levels.

3. Know how the tasks are related among engineers, (this is on the roadmap, not in production). We want to throw data to know how the tasks are distributed among the engineers, how the reviews work among them, what level of involvement exists, how the workflow with the PRs improves, number of comments by type of task or by person, .. We are working on providing data that can help to better structure processes internally. With this, we want to get engineers to communicate more with each other and increase motivation and the level of involvement among colleagues.

4. Impact of the tasks. At a low, medium and high level. We establish criteria based on an algorithm (constantly evolving) based on good practices within the code: comments, revisions, affected dependencies, modified lines, labels, commit message, type of task, etc. With this, we help you understand the impact level of each pull-request in the code. We help detect talent, lack of motivation, progress from a junior to senior engineer, ... We want to connect with Sonarqube tools to really see if that impact we reflect is directly related to the technical debt in Sonarqube.

And on the roadmap, there are more things. We want to make a very cool tool, and feedbacks like yours help us greatly!

Once again, thanks knight! Anything, write me again!

Hi there again knight!

As you can imagine, we are a Startup actually consolidating our product. We are in Seed stage so every feedback we receive (like yours) makes us very happy and prouds and helps us tons! So thank you again for taking your time to ask me questions!

Since we are validating some of our visualizations and insights, not all people will find the value, while others do. In our case, some of our customers are using the "Impact" visualization to gamify some way the code process with the engineers so they are more motivated and have increased the quality of their processes overall.

You are probably right by saying that our provided data could be not the right data to make decisions. It will depend on you and the value you find in that information we provide.

As I told you, we are validating and you are free to talk to me and write me your pains if you have them!

Thanks again knight!

Haha yes, you are :)

What you should expect when viewing these metrics as Project Manager is to know the workflow of your engineers, not the risk associated with each of the tasks.

In relation to your question, the impact determines the level of involvement of each PR within the repository. Not necessarily greater impact implies greater risk, but a better quality of the task in short.

In the end, what we need is data to make decisions based on something palpable.

Thanks for your reply knight. Treating matters from this perspective is always positive and I take it as good feedback.

First, there are things that I agree with and others that I don't agree with. Work organization methodologies are a first approach to real problems but they are not the final solution. The metrics that I present are nothing more than an approach from which to face the problem and have data to make better decisions.

1. Activity Days not only shows the modified lines or the affected units. It generates a report of all the activity in that sprint if you click on the blue button and it shows you all the tasks performed in that sprint with an associated impact value.

2. Impact is not associated with risk at any time, it is associated with an algorithm that determines among other things the level of dependencies affected, message of the commit or lines affected by a commit.

3. Code churn is nothing more than an approximation to know when there has been more flow of changes in a specific repository.

4. The flow of all work is something we are working on in scope.ink for the next releases. We will integrate exactly what you have written: how the entire flow of a task works from the moment it opens until it closes and how the work is connected between the software engineers. In any case, software factories help them know the average time of tasks to make better cost projections.

Thank you for your contribution knight and we keep in touch!

Thanks for your reply tanseydavid!

Yeah, probably the not planned work escapes control and it probably produces most of technical debt.

It could be measured in some way by stablishing goals, perhaps?

Thanks for your reply yitchelle! The image only shows a part of the graph. When you click on the circle it shows all the activity in the concrete week and the impact of those tasks and their impact on the repository!

So yes, activity days show how busy is an engineer and what he/she's really doing!

which ones would you consider to analyze or to follow?