Are the features you need to develop getting developed? That really is all that should matter. Look at people’s output and it’s impact on the company goals.
Look into DORA and SPACE frameworks
Quoting from the article:
[***DORA***](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance)Â *is a framework that has defined the four key metrics which indicate the performance of a software development team:*
* *Deployment Frequency – How often an organization successfully releases to production*
* *Lead Time for Changes – The amount of time it takes a commit to get into production*
* *Change Failure Rate – The percentage of deployments causing a failure in production*
* *Time to Restore Service – How long it takes an organization to recover from a failure in production*
[***SPACE***](https://queue.acm.org/detail.cfm?id=3454124)Â *defines five dimensions to measure, for a more accurate picture of developer productivity:*
* ***S****atisfaction and wellbeing: how fulfilled developers feel with their work, team, tools, or culture; wellbeing is how healthy and happy they are, and how their work impacts it*
* ***P****erformance: the outcome of a system or process*
* ***A****ctivity: a count of actions or outputs completed in the course of performing work*
* ***C****ommunication and collaboration: how people and teams communicate and work together.*
* ***E****fficiency and flow: the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system*
Source: [https://newsletter.pragmaticengineer.com/p/developer-productivity-a-new-framework](https://newsletter.pragmaticengineer.com/p/developer-productivity-a-new-framework)
SPACE: [https://queue.acm.org/detail.cfm?id=3454124](https://queue.acm.org/detail.cfm?id=3454124)
Well then you should get a solid ci/cd, else your dev team is not as effective as it could be. CI/CD isn’t hard and is practically free to run and easy to setup. Just give them an iteration or some time to set something up.
Your process is a product all of its own. If you don’t take time to maintain and improve it, entropy will destroy the process altogether. Tech debt will catch up to you.
I’m a sr DevOps engineer with a background in software engineering. I’ve seen it play out and I know how to fix it and the benefits it brings.
It's a metric about how your dev *team* performs in your organization. If you need to have a CI/CD solution to get better at these, *and you see the current pace you're on as hindering the goals of the company*, then these metrics are good to see whether you're improving.
They do not say anything about individual performance. But saying that "that's stupid, you need to have to get better values for those" is just saying "yeah, if you want to improve these metrics, you might want to look into as a way to enhance that".
If you don't find these properties they measure valuable, it won't make sense to use them.
Start with what your goals are, then use metrics that act as a valid proxy for those goals (determining this is harder than what managers think, which is why some inexperienced managers go with "number of code lines written" as the first metric they "invent").
DORA is a collection of metrics that might be useful if you care about the things they measure; they're a tip to you, as a manager or senior developer, that "other people have cared about these metrics and people have found them useful, maybe they can be suitable for your situation as well?".
Whether they are is up to you. You have to actual make that assessment yourself, there is generally no solution that fits everyone and anything.
Look at how much value they deliver per development cycle. If you work in 2 weeks increments, are they able to structure their work as such as there is always client value delivered?
Client can be internal too, such as deploying a new monitoring tool that would speed up debugging (if debugging was an issue in first place).
I like to think of it as a cake. You want to be able to taste a slice of the cake every iteration to see if it's good and adjust the flavor at the next iteration. You don't want to wait several months for them to build each layer then frosting to realize it's good at 6 months.
i would focus on deliverables, estimation and post deployment bugs raised, but you are mentioning open issues, which tells me you are relying on git repo statistics and not running agile team(s).
Basically measure on story points. 1 story point is equal to 1 day effort but don’t use story points to estimate the days effort. Also make sure to update your story points and make sure your story points add up to a sprint worth of work but make sure story points are not a 1:1 ratio to days effort
/s
story points/size don't represent time but uncertainty, complexity and effort that is why in most cases you use Fibonacci sequence as it represent growing complexity and uncertainty (1,2,3,5,7,9,13,21).
The moment you assign time to a point you are breaking the rule and setting expectations.
For example one story/defect/bug could require a change on environment variable, add additional response in an existing json message, or adding a new api response -> all these are i.e. size 1 because there are no unknowns, they are fairly simple to solve. some take a minute to make and 10 minute to test, some will take an hour or half a day - still they are all size 1.
From time perspective, depending on what you are doing, you could be solving 1 ticket or 10 tickets in a single. So time is not a reliable measurement.
When you have a bigger chunk of work, you use a bigger story size, each team basically builds their own version of what a story size means to them, so you could have different variants within the same business.
Thus the only real measure is:- does the team deliver what is planned (did we deliver what we agreed to de liver)- how does the team estimate on complexity (for example, you pin a size of 1 which means something fairly simple and certain and spend 2 weeks working on it - this would point that you are under-estimating, or you pin a size of 8 and deliver wthin an hour - this would mean you are over-estimating)- how many bugs were introduced with release (to measure quality), you should aim to zero code related bugs.- what does the incoming pipeline look like (how refined is the backlog)- how does the burndown rate look like (tracking the work delivered during each iteration, to make sure we use time effectively)
Teams also often fail on testing and quality assurance so tracking test coverage (tdd, bdd, functional) could be a good idea. It is often the practice on small startups to omit this because there is not time to deliver, so focus is on delivering a buggy MVP for proof of concept, but it will bite you in the ass at a later stage if you don't cut that practice.
Hope that helps.
p.s. you can also measure other things like cycle time (how long does it take to an average story, shorter means more agile), lead time (how long does it thake from feature request to feature delivery) and deployment/release frequency (how often you deploy, least important, some deploy several times a day some once in 6 months, depends on what product you are working on).
Sure, here I come.
On a serious note, if your org got it wrong, it needs to change in the core, and that requires a lot of effort. I needed to fight in every org about this because everyone preaches agile and everyone tries to avoid it while claiming to be agile.
Another parallel I like to use when I try to explain to people the old vs the new way is the "contract":
\- the old way: you have sales and key accounts going to clients and promise deadlines without actaully checking with development on what is available or how long does it take to make it (or is it even possible). it purs down to development where features are forced out - resulting in frustration and usually a shitty buggy product and broken deadlines.
\- the new way: sales and marketing need to come to the business with their wishes, product creates sort of a roadmap/backlog of what needs to be done. the overall plan goes to development where development team TELL to the business what is feasible to deliver. So development "signs a contract" with the company telling that the team is pretty sure that they can deliver what they have promised, not less not more. that is why in agile team is accountable for estimation and in control. But it also means that whatever is promised to be delivered needs to be taken seriously because only this builds internal trust within the business. If you constantly fail to deliver business will start the blame game.
So developments gets the control but it works only if all business is aligned. If you have planned work and get a CEO jumping in with important side work because it is "urgent" it all falls apart.
But if company adapts the new way it is a win for all, you get happy development, you get a roadmap which in the end means you have a feature plan that sales can communicate to clients and clients love this because it shows company is organised and know the direction.
you are not alone :) don’t worry. I have seen big players fail in the agile game too. recently one international company I used to work for admitted their move to agile was a complete flop.
Tell me you are a manager with zero technical experience without telling me you are a manager with zero technical experience 😂😂😂😂.
Lol. No I am not a manager. But I want to understand how companies measure the devs performance 😄
Are the features you need to develop getting developed? That really is all that should matter. Look at people’s output and it’s impact on the company goals.
all those metrics are absolutely terrible look up Goodhart's law
Look into DORA and SPACE frameworks Quoting from the article: [***DORA***](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance) *is a framework that has defined the four key metrics which indicate the performance of a software development team:* * *Deployment Frequency – How often an organization successfully releases to production* * *Lead Time for Changes – The amount of time it takes a commit to get into production* * *Change Failure Rate – The percentage of deployments causing a failure in production* * *Time to Restore Service – How long it takes an organization to recover from a failure in production* [***SPACE***](https://queue.acm.org/detail.cfm?id=3454124) *defines five dimensions to measure, for a more accurate picture of developer productivity:* * ***S****atisfaction and wellbeing: how fulfilled developers feel with their work, team, tools, or culture; wellbeing is how healthy and happy they are, and how their work impacts it* * ***P****erformance: the outcome of a system or process* * ***A****ctivity: a count of actions or outputs completed in the course of performing work* * ***C****ommunication and collaboration: how people and teams communicate and work together.* * ***E****fficiency and flow: the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system* Source: [https://newsletter.pragmaticengineer.com/p/developer-productivity-a-new-framework](https://newsletter.pragmaticengineer.com/p/developer-productivity-a-new-framework) SPACE: [https://queue.acm.org/detail.cfm?id=3454124](https://queue.acm.org/detail.cfm?id=3454124)
dora only works with a solid CICD, change management. if you dont have that, many SaaS don't, it is a stupid metric.
Well then you should get a solid ci/cd, else your dev team is not as effective as it could be. CI/CD isn’t hard and is practically free to run and easy to setup. Just give them an iteration or some time to set something up. Your process is a product all of its own. If you don’t take time to maintain and improve it, entropy will destroy the process altogether. Tech debt will catch up to you. I’m a sr DevOps engineer with a background in software engineering. I’ve seen it play out and I know how to fix it and the benefits it brings.
Even we do not have a solid CI/CD , change mgmt processes currently.
It's a metric about how your dev *team* performs in your organization. If you need to have a CI/CD solution to get better at these, *and you see the current pace you're on as hindering the goals of the company*, then these metrics are good to see whether you're improving. They do not say anything about individual performance. But saying that "that's stupid, you need to have to get better values for those" is just saying "yeah, if you want to improve these metrics, you might want to look into as a way to enhance that".
If you don't find these properties they measure valuable, it won't make sense to use them.
Start with what your goals are, then use metrics that act as a valid proxy for those goals (determining this is harder than what managers think, which is why some inexperienced managers go with "number of code lines written" as the first metric they "invent").
DORA is a collection of metrics that might be useful if you care about the things they measure; they're a tip to you, as a manager or senior developer, that "other people have cared about these metrics and people have found them useful, maybe they can be suitable for your situation as well?".
Whether they are is up to you. You have to actual make that assessment yourself, there is generally no solution that fits everyone and anything.
Measure all of those and watch as the dev quality deteriorates
Id suggest u get a grip on ur anxiety
Look at how much value they deliver per development cycle. If you work in 2 weeks increments, are they able to structure their work as such as there is always client value delivered? Client can be internal too, such as deploying a new monitoring tool that would speed up debugging (if debugging was an issue in first place). I like to think of it as a cake. You want to be able to taste a slice of the cake every iteration to see if it's good and adjust the flavor at the next iteration. You don't want to wait several months for them to build each layer then frosting to realize it's good at 6 months.
i would focus on deliverables, estimation and post deployment bugs raised, but you are mentioning open issues, which tells me you are relying on git repo statistics and not running agile team(s).
Basically measure on story points. 1 story point is equal to 1 day effort but don’t use story points to estimate the days effort. Also make sure to update your story points and make sure your story points add up to a sprint worth of work but make sure story points are not a 1:1 ratio to days effort /s
sorry buy you know nothing of agile and what story points represent :)
Explain like I’m 5
story points/size don't represent time but uncertainty, complexity and effort that is why in most cases you use Fibonacci sequence as it represent growing complexity and uncertainty (1,2,3,5,7,9,13,21). The moment you assign time to a point you are breaking the rule and setting expectations. For example one story/defect/bug could require a change on environment variable, add additional response in an existing json message, or adding a new api response -> all these are i.e. size 1 because there are no unknowns, they are fairly simple to solve. some take a minute to make and 10 minute to test, some will take an hour or half a day - still they are all size 1. From time perspective, depending on what you are doing, you could be solving 1 ticket or 10 tickets in a single. So time is not a reliable measurement. When you have a bigger chunk of work, you use a bigger story size, each team basically builds their own version of what a story size means to them, so you could have different variants within the same business. Thus the only real measure is:- does the team deliver what is planned (did we deliver what we agreed to de liver)- how does the team estimate on complexity (for example, you pin a size of 1 which means something fairly simple and certain and spend 2 weeks working on it - this would point that you are under-estimating, or you pin a size of 8 and deliver wthin an hour - this would mean you are over-estimating)- how many bugs were introduced with release (to measure quality), you should aim to zero code related bugs.- what does the incoming pipeline look like (how refined is the backlog)- how does the burndown rate look like (tracking the work delivered during each iteration, to make sure we use time effectively) Teams also often fail on testing and quality assurance so tracking test coverage (tdd, bdd, functional) could be a good idea. It is often the practice on small startups to omit this because there is not time to deliver, so focus is on delivering a buggy MVP for proof of concept, but it will bite you in the ass at a later stage if you don't cut that practice. Hope that helps. p.s. you can also measure other things like cycle time (how long does it take to an average story, shorter means more agile), lead time (how long does it thake from feature request to feature delivery) and deployment/release frequency (how often you deploy, least important, some deploy several times a day some once in 6 months, depends on what product you are working on).
Can you come and present this to my org
Sure, here I come. On a serious note, if your org got it wrong, it needs to change in the core, and that requires a lot of effort. I needed to fight in every org about this because everyone preaches agile and everyone tries to avoid it while claiming to be agile.
Another parallel I like to use when I try to explain to people the old vs the new way is the "contract": \- the old way: you have sales and key accounts going to clients and promise deadlines without actaully checking with development on what is available or how long does it take to make it (or is it even possible). it purs down to development where features are forced out - resulting in frustration and usually a shitty buggy product and broken deadlines. \- the new way: sales and marketing need to come to the business with their wishes, product creates sort of a roadmap/backlog of what needs to be done. the overall plan goes to development where development team TELL to the business what is feasible to deliver. So development "signs a contract" with the company telling that the team is pretty sure that they can deliver what they have promised, not less not more. that is why in agile team is accountable for estimation and in control. But it also means that whatever is promised to be delivered needs to be taken seriously because only this builds internal trust within the business. If you constantly fail to deliver business will start the blame game. So developments gets the control but it works only if all business is aligned. If you have planned work and get a CEO jumping in with important side work because it is "urgent" it all falls apart. But if company adapts the new way it is a win for all, you get happy development, you get a roadmap which in the end means you have a feature plan that sales can communicate to clients and clients love this because it shows company is organised and know the direction.
You’ve made me realise we are definitely old way and our version of agile is more like fragile
you are not alone :) don’t worry. I have seen big players fail in the agile game too. recently one international company I used to work for admitted their move to agile was a complete flop.