Stress estimation and tracking experiment: any recommendations?

[philou]

Hi,

In some context, 'value generation' is not a big enough incentive for teams to change their behaviors! For example:

• teams are stuck in a long batch delivery mode, they don't see the value of delivering early because nothing will hit a customer before one year anyway
• dev teams are mostly 'executors' and they don't really care if their employer gets more value or not, for them, life is still going to look like "Stories in, stories out..."

These work environments are far from ideal, but unfortunately, they are still very common. In order to try something new, I thought we could tweak the extreme carpaccio to estimate the stress level of the different seller teams. This way we would see that the way they work has a direct impact on their working conditions. I thought about estimating stress by summing 3 factors:

• Something proportional to the income difference with leaders (when you are not performing well on the market, you get pressure)
• Something proportional to the time since last 'earning' (when you don't deliver anything new for a long time, you get pressure)
• Something proportional to any money lost, that would then decreases with time (bugs in production generate a lot of pressure)

I would need to add a new graph for stress levels on the main screen. At the end of the sessions, seller teams could compare and discuss their stress graph and the way they worked.

Here are my questions:

1. Would you be willing to accept such an enhancement in the main codebase?
2. Are there any points you would want me to keep in mind?
3. Would you prefer a large PR or many small ones? I will use small commits anyway.
4. Have you got any coding or design recommendations?

Thanks a lot for this project.

[dlresende]

Hi @philou.

Thank you for taking the time to propose an enhancement.

If I understand the fundamental issue you would like to address, you are saying some teams feel disconnected from how much money the company is making.

I definitely can see this happening in many places with silo-ed cultures.

Although, I think fully addressing this concern goes beyond the scope of this exercise as it was intended.

Extreme Carpaccio was designed assuming participating teams (developers + product managers) would "feel the heat" by seeing their competitors making money before them.

Sometimes this does not happen. I've facilitated sessions where all teams felt they had loads of time and it took a while until the first Order got through.

Generally when I see this happening, I try to compensate through facilitation, by engaging with teams, giving them more hints and perhaps doing some coaching so that they can earn their first penny a bit sooner and break this dynamic.

I am afraid adding some metric to measure stress or pressure would not create that feeling of commitment and urgency you seem to be hinting at.

Also to help in those situations, there are some tweaks facilitators can tap into.

Or maybe I'm not seeing what you are seeing. In this case, feel free to fork and put something together. I am happy to have a look if you want to.

If you decide to do so and I am still of the opinion it goes beyond the purpose of the exercise and decide not to merge, I will be happy to refer to your fork in the README if you think this helps.

[philou]

Hi @dlresende

Thanks for your answer. I understand your point of view. I'll hack something to experiment with running a few sessions with this idea. I'll be able to give you better feedback at that time.

If these experiments prove that there is some value in this modification, would you consider accepting a change for some kind of plugin system? So that I could avoid having to maintain a full fork of the original repo.

Thanks again

[dlresende]

Happy to have a look once it's done.

[jak78]

Hello. I made a fork to play with legacy code: teams get points when they implement new feature without breaking the current behavior in 'production'. I introduce new rules to implement, one at a time. They get more points if they implement the new rules successfully, but they get a high penalty if they break the existing behavior. That's another fork to maintain, so I'm not the only one that would benefit from a kind of plugin system. I would be happy to help on this, let's start by having a design discussion with @philou & @dlresende about it :-)

[philou]

Hi,

@jak78: actually, regressions were on my list of pressure-generating things, but I thought it would be too difficult to track in the prototype of my stress-tracking extreme carpaccio. I'll have a look at your fork to see how you did it, is the fork on Github?

I managed to create an excel prototype that estimates 'stress level' according to sales and losses. It's not realtime, and requires a bit of manual labor at the end, but it should help us to see if this idea is worth pursuing.

For the moment, I've only been exploring and just started experimenting a bit with the code, so I don't have clear design propositions around the plugin system. Plus it really depends on what needs to be parametrized. @jak78: How did you implement regression tracking?