How do you evaluate the effectiveness of your team's development processes over time?
Posted by senpaicataner@reddit | ExperiencedDevs | View on Reddit | 11 comments
As experienced developers, we often implement various development processes and methodologies to enhance team productivity and output quality. However, evaluating the effectiveness of these processes can be challenging. In my experience, it’s crucial to establish clear metrics and feedback loops to assess how well our current practices serve the team's goals. This could involve tracking key performance indicators (KPIs), conducting regular retrospectives, or soliciting anonymous feedback from team members. I’ve found that fostering an open environment where team members can discuss what's working and what isn't greatly contributes to process improvement. What methods have you found effective in evaluating and iterating on your team's development processes? Have you had experiences where changing a process led to significant improvements, or conversely, where a change didn't yield the expected results? Let’s share insights on best practices and lessons learned.
overlook211@reddit
Can we remove obviously AI generated posts?
nein_va@reddit
Agreed
superdurszlak@reddit
We have regular Development Experience surveys, where the goal is to improve on the aspects where the score is lowest (there are the most negative responses about).
Retrospectives where complaints result in action items, not complaining on the same thing next time or worse, scolding. You can really go a long way by having action items for most voted items, and then have someone own it.
If the team keeps complaining about the same thing over and over and nothing gets done to make it less of a pain, it may mean the team isn't or doesn't feel empowered to do anything about it. It maybe they just like complaining, but I would assume lack of empowerment, typical in places with a strong hierarchy and a top-down feedback-tolerated-not-welcome places.
If team members get scolded and repeimanded for speaking up, or worse, humiliated, then the process will be whatever the local omnipotent demigod wants it to be, and you'd better not share your thoughts so any kind of feedback won't be effective. I've seen people being anxious about anonymous feedback forms because they were afraid their answers would be traced back to them.
There's also this special, unhealthy culture of forced positivity, where nobody would tell you in your face that you shouldn't have spoken up, and yet you just end up smiling when they want you to smile, and clapping your hands when everyone else claps.
So yep, it's all about empowerment, integrity, sense of safety. Specific processes are only means to express the culture and vibe - be it through retrospectives, tracking metrics (which are often gamed anyway), surveys or community of practice. Nothing works if us grunts can do nothing about our fate.
Infinite_Maximum_820@reddit
Are they delivering value or not to the business and why not if not
lapinjuntti@reddit
Recognize what is the value that you are delivering and then design the metrics around that.
If you are developing something new your target may be creating a new product and turning it profitable as fast as possible. In this case, you will optimize for learning fast.
If high productivity and quality are your main targets, then there's great books such as toyota production system, lean, etc.
But remember, that top productivity may not always be the target. Sometimes you can deliver higher value even though your productivity is not that optimal. So it is really important to understand in what situation you are in and for what you should be optimizing for.
rwilcox@reddit
How often do world changing events happens to them? (People leaving the team, people joining the team, reorgs etc)? I know a team where a significant event like this happens every quarter. No team can be effective with that leave of constant churn.
How many pages do they get per month?
How many big fix deployments - or full production deployment reverts - do they have per month?
…. In addition to maybe the DORA metrics
Individual-Praline20@reddit
Easy. Only one thing matters. Is the customer happy? Scale 1-10. All the rest is bullshit and time waster. Yep, including the so godly velocity and these f.cking crappy metrics.
i_exaggerated@reddit
DORA metrics are the only thing I give weight to
valence_engineer@reddit
I remember reading that a process change will often look positive for \~6 weeks since the social pressure of leadership looking will drive some short term productivity. Then it will regress to the actual long term value. That may be a above the original value or below it.
So you need to update your processes rarely enough that you have time to wait out the initial period and then look at the results versus your original baseline (not the baseline right after the change). You also need the discipline to ignore the results right after a change.
The worst you can do is get into a process optimization feedback loop of death. You make a change, it looks good, then thing decay a bit, it's just a reversion to the mean but you think its an actual drop, so you make a new process, looks good, then it drops, so you make another process change, etc, etc, etc.
throwaway_0x90@reddit
These questions definitely sound like data-mining for AI.
Strict-Soup@reddit
Why don't you ask the team you're wanting to get metrics on?