9 ms·

I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into wha

I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. The sad truth is that most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. Especially if nobody can actually quantitatively measure the loss of efficiency.

ptmcc 4y ago
I agree. In my experience that outside visibility is mostly a mirage. Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years. In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on top to satisfy management and/or external parties.
- rightbyte 4y ago
  Ye padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all. -"It is impossible to do accurate estimates" -"You will get better at it" I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". Do anyone else share this experience?
  - emodendroket 4y ago
    Estimation often is way off for construction projects, but would you hire a contractor who refused to hazard a guess of how long a job would take or how much it would cost?
    - gilbetron 4y ago
      Constructions remains a terrible analogy for software development, as it always has been.
      - emodendroket 4y ago
        Would you agree to pay for any service where not even an estimate of the price could be given? I guess healthcare is the only example I can think of where anyone consents to that.
        deleted 4y ago
        [deleted]
        davemp 4y ago
        Estimates you get are what the estimator thinks you will pay (mostly) not how much it costs them. Prices in the real world are barely linked to costs. Budget risks are bundled in markets with high variance.
        emodendroket 4y ago
        Even to the extent that is true it doesn’t change my argument at all.
        davemp 4y ago
        Maybe I don't see the relevance of your question then. Software developers are not negotiating fixed price contracts with their project managers every two weeks. Just how toxic such a situation would be should be obvious. Managers need to understand the context of the job and determine if they're satisfied with the productivity of their employees. Agile is a development process not a contract pricing strategy. If anything proponents of "Agile" would be more hesitant to quote you a firm fixed price contract than "Waterfall" teams.
        4y ago
  - lucumo 4y ago
    Is padding really cheating? I'd describe that as accounting for unforeseen setbacks and correcting for overenthusiastic optimism.
    - rightbyte 4y ago
      Padding estimates is fine. But not when you report actual worked time, which was what we did to make management happy with the burn down charts straightness. If you don't report actual time for the task, the excercise is useless. E.g. shift work time from a slower than estimated task to a faster, or "wait" if the task was done too quickly.
  - watwut 4y ago
    Imo, padding estimates is not cheating. It is just doing estimation right. Teams that do not pad estimates literally always underestimate amount of time needed.
  - JohnFen 4y ago
    > I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". I was a trained Scrum Master and I knew this very well.
    - ResearchCode 4y ago
      What's a trained "scrum master"? I thought the certs don't even have exams.
- Kichererbsen 4y ago
  Totally with you. But since I'm currently preparing to get certified for Scrum, I'd like to point out that all those things you mentioned above aren't really part of Scrum at all...
- robertlagrant 4y ago
  All the estimation stuff is only for your team, not for outside consumption. If you release it and care what people say about it, then that I don't think that's the methodology's fault.
kqr 4y ago
For the purposes of understanding the way people act, it is important to focus on what they believe to be the truth, not what the truth is. Software development is incredibly opaque by default (heck, even we don't know how far along we are, most of the time) so anything that improves that will be perceived as improved productivity. But even if it's not, sometimes progress reporting (however rough) is needed to synchronise with other parts of the organisation. It just needs to be put into a form that is useful (e.g. for agile projects "percent of plan delivered" is not a useful metric) and how it's going to be used should be explained to those producing it. Heck, optimal is if the people making software and the people they need to coordinate with can get together and jointly agree on what type of reporting is actually meaningful for both parties. Almost always, we're discussing vanity metrics though.
enkid 4y ago
Having predictability and observability is key to a business though, as higher level decision need to be made based on progress of the lower level teams.
- kqr 4y ago
  In my experience, if the business has a higher level decision that depends on the progress of a lower level team, the only working approach is for the manager in charge of that decision to sit down with a person in the lower level team and discuss the state of things. A metric compresses a very rich and nuanced opportunity into a false dichotomy.
- danmaz74 4y ago
  Yes, predictability is better for business, but business also needs to accept that there are limits to the amount of predictability you can achieve in software development, and trying to force too much process is only going to predictably increase delivery time. In my experience, working with high level estimates which you keep updating from time to time is the best compromise.
  - kqr 4y ago
    There's no limit to predictability achievable in software development per se. You can have perfectly predictable software development -- if you know exactly what it is you're going to build. The trouble is -- as with any product development -- we don't know exactly what we are going to build because it depends on fickle market sentiments, new technology, etc. That is what sets the upper limit on predictability, and that can be controlled by high level decisions. (Unfortunately, increased predictability usually means decreased profitability.)
    - deleted 4y ago
      [deleted]
    - danmaz74 4y ago
      > You can have perfectly predictable software development -- if you know exactly what it is you're going to build. That's not enough - you can have pretty good predictability if you know exactly what you're going to build, and if you already built the same kind of thing with the same technologies/tools that you're going to use this time. Which is very often not the case: business very often wants new things that others don't already have, or the technologies/tools from previous times are now outdated (or believed so...).
fendy3002 4y ago
The problem is even scrum doesn't give the predictability and observability better than kanban. It's extremely hard to predict what we need to do in next 2 weeks and what we can achieve in next 2 weeks. At my current company, half, if not more, of the tickets come in mid-sprint. So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain amount of story points, then add / remove as the sprint is going.
- throw3823423 4y ago
  I have seen a very predictable scrum, but the tradeoffs with productivity were comical. In this very large corporation, most developers could do most of the tasks in their 2 week sprints in 3 days of actual work. But they don't know if they are going to get 3 days of actual work, or some other team is going to keep master broken for a week. Therefore, your typical sprint involves mostly fictional standup updates, as to make sure that, when things go more than a little too well, the shameful levels of sandbagging aren't visible in jira or in git. If you ask me, that level of predictability is a poor tradeoff, but hey, it's the same kind of organization that decides that SAFe scrum is a serious methodology.
  - robertlagrant 4y ago
    SAfE is definitely a bad idea, but keeping master broken should be a "automated tests guard master" retro action.
    - gedy 4y ago
      These type of problems usually are not "actionable" with big legacy apps, poor coverage, etc.
      - robertlagrant 4y ago
        Someone who's not a technical junior needs to make it very clear that breakages will keep happening and support staff will need increasing if no one has the time to figure out a test harness or similar for the software in question. If people are literally blocked because someone else has broken master then they should be working on a test harness right now, in fact. That would actually be useful.
robertlagrant 4y ago
I think I'd pick any team, not just software, telling me when something will exist over them saying they're more efficient. Efficient isn't even a metric I'd understand in most cases, e.g. a plumber telling me the house will be done as efficiently as possible but I won't know when any particular room will be unavailable so I can't plan around that info.
- alfons_foobar 4y ago
  But isn't the problem exactly that, that oftentimes we cannot know in advance how long it will take to implement X?
  - tharkun__ 4y ago
    I think your parent is trying to say that you won't hire the plumber that only tells you he will be efficient doing his job. But you will hire the plumber that tells you "if I don't find surprises behind the wall, this is a 2 hour job". And then he opens up the wall and finds old corroded iron piping he has to trace down to where it attaches to the main line and replace it all or else you won't get your new bathroom done at all. And that job takes more than 2 hours. You could also have said "well if that's the case can you poke some exploratory holes in the drywall please so I can get a better estimate" (aka a "spike").
Double_a_92 4y ago
I've seen many people complain about reviews and retrospectives in those threads... But they don't seem like a bad thing to me. The problem is if the sprint is too short. But if the review and retro are done e.g. once every month or so, it can be a good way to see what the other teams have been doing and get an overall picture of your software. And the retro can be a good opportunity to talk about any problems that you encountered, and maybe trigger a solution, or at least just vent about it.
- re-thc 4y ago
  The problem is nothing comes out of it. We run retros and there are action items and they go into a black hole. The higher ups do it to follow the process and not to fix the actual problems. It gets tiring after a while of time wasting.
- watwut 4y ago
  I do not want to talk about these problems again and again and again. I would like to see some improvements. First few times it works as a psychohygiene, but then it just becomes annoying. So teams stops talking about actual deep issues on those meetings and they are are creating an illusion of happiness.
s-lambert 4y ago
I don't see retrospectives being that much of a time-sink, it's a 30min/1hr meeting every 2 weeks. Even when I was on a kanban team they still had a fortnightly retrospective, it's useful to have a checkup occasionally.
- hgsgm 4y ago
  Every time someone hates Scrum they always complain about 2 week sprints, which are an insane choice (should be 4 weeks), that shows they aren't doing Scrum, they are micromanaging with "Scrum" as the excuse.
  - Clubber 4y ago
    Yes, I don't know where the 2 week sprint thing came from, but everyone uses it as a default. I've tried to get it to 3 or 4 weeks but always get resistance. The main reason I think is the business wants their features NOW.
  - ryathal 4y ago
    Going longer than two weeks for a sprint just makes the lies happen at different place. There are approximately 0 teams that can accurately state all the work they will need to do four weeks in advance, even two is a stretch. Planning and retro per sprint become a burden though, on less than two week sprints.
  - icedchai 4y ago
    I currently work at a place that does 1 week sprints. It's bad.
darreninthenet 4y ago
This is just doing scrum badly... management break it by insisting the metrics etc are used as a reporting mechanism, they just cannot get away from "intensive control mode". The metrics are supposed to be for the team to use internally. But I do agree with the post - Kanban is way way better and you can include the scrum continuous improvement elements as well on a regular cycle.
- Jochim 4y ago
  > The metrics are supposed to be for the team to use internally. You've already pointed out that this is basically unheard of but I'm struggling to think of situations where scrum metrics have provided benefits that outweighed the cost of taking, and exposing them. My experience has been that most development teams intuitively recognise problems that might be revealed by these metrics. Is this not often the case?
  - darreninthenet 4y ago
    This is where a decent scrum master or agile coach is valuable - fighting off the misuse of the metrics by external (to the team) management. The thing is with metrics is that they are hard to argue with, whereas intuition is a debatable opinion. Perhaps not everyone in the team agrees. Perhaps it's about showing interfering management or dependent teams where the issues lie. Perhaps the team doesn't realise how long a particular stage in their workflow is holding things up - I mean they know that stage is a problem but have they realised it's actually their biggest blocker to finishing work? Also depending on what you use to generate metrics - something like ActionableAgile that use Monte Carlo simulations against a few weeks worth of activities can show a team what their cycle time is, what items are in danger of blowing that and how long it's likely to finish just their current backlog (for example). As you say, in their worst case they tell teams what they already know and then again that's the value of a good SM or AC - finding out why nothing is being done about it (whilst beating away interfering managers).
DoingIsLearning 4y ago
>The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. Agree with everything _expect_ retros. I think the value of the retros is proportional to how senior the team is and to how seasoned managers are. But for me retros are extremely high value _if_ you have: - Teams that can look at problems head on and be civil addressing things without making it personal. - Managers that have a 'clear roadblocks' mindset and have a service-providing mindset towards the team. In this scenario you can really have high value retros, with continuous adjustments to workflow, processes, design, without continuously repeating the same mistakes or falling in the same pitfalls.
- lucumo 4y ago
  I found that retros tend to devolve into gripe sessions when the team isn't able to change its environment. Best to keep them focused on things they can actually change, and just to let them fix what they need instead of talking about it. Also, after an initial stabilisation period, teams need fewer and fewer changes. Talking about it every sprint gets really pointless and takes time away from the things they're good at and they're motivated to do.
  - przemo_li 4y ago
    Proposing retro board be available 24/7 and retros be skipped if board is empty is good use of retro time. ;)
    - bluefirebrand 4y ago
      This sounds amazing. But I do wonder if it just encourages people not to bring up real problems so that they can skip a meeting. I think having the board up at all times is a great idea though. Just have to have some way to figure out "is it empty because things are fine or is it empty because no one cares anymore".
- sodapopcan 4y ago
  I've worked on a team that had amazing retros: lots of difficult discussions that resulted in change. We also made sure to discuss positive things too to ensure they keep happening. I think a lot of people miss this about retro. I also worked on a team with terrible retros. The "good" column would always be extremely long and was only full of platitudes, nothing of actual substance that was brought forward into the next week. If anything difficult came up, someone would say, "Ok, let's book a meeting to talk about this later". It was an extreme misunderstanding of the value of retros. Though everyone else seemed to enjoy them so that's arguably valuable? I dunno. Anyway, yes, lots has been said on this topic in the past. SCRUM is just Agile for stakeholders. There is the whole "SCRUM But" joke but I actually think a bunch of things in SCRUM are valuable BUT if something isn't working out, don't do it! I get the impression that lots of companies just do all the rituals "because SCRUM" and don't actually understand why they are doing them. Case in point, I was at a company that would always spend time story-pointing but no one ever looked at them. Not the teams and not the stakeholders.
ithkuil 4y ago
> Especially if nobody can actually quantitatively measure the loss of efficiency. Yet ironically they care and tout about their ability to measuring efficiency. An easy way to boost efficiency: hide inefficiency out from view!
gofreddygo 4y ago
> most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. we're in this exact phase - sacrificing efficiency, team morale and independence to make the boards look cleaner to "raise the bar" per se. We're a small efficient team in a massive org. Manager does a great job of not making stupid decisions, values people's time and is clear about the metrics the team gets evaluated on. somewhere along the way he's, missed the reality that clean user stories and tasks, complete with points down to hours and acceptance criteria can still be completely f$#king wrong compared to the actual work that needs to be done. Not because the people are idiots but because thats how most software work is. You find out when you actually start working on it. But if you mandate that you need a well cut plan before code gets written, you mostly get well written $hit. We just embarked on this journey which I can mostly predict the outcome of. sad, true.

ptmcc 4y ago

I agree. In my experience that outside visibility is mostly a mirage. Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years. In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on top to satisfy management and/or external parties.

rightbyte 4y ago
Ye padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all. -"It is impossible to do accurate estimates" -"You will get better at it" I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". Do anyone else share this experience?
- emodendroket 4y ago
  Estimation often is way off for construction projects, but would you hire a contractor who refused to hazard a guess of how long a job would take or how much it would cost?
  - gilbetron 4y ago
    Constructions remains a terrible analogy for software development, as it always has been.
    - emodendroket 4y ago
      Would you agree to pay for any service where not even an estimate of the price could be given? I guess healthcare is the only example I can think of where anyone consents to that.
      - deleted 4y ago
        [deleted]
      - davemp 4y ago
        Estimates you get are what the estimator thinks you will pay (mostly) not how much it costs them. Prices in the real world are barely linked to costs. Budget risks are bundled in markets with high variance.
        emodendroket 4y ago
        Even to the extent that is true it doesn’t change my argument at all.
        davemp 4y ago
        Maybe I don't see the relevance of your question then. Software developers are not negotiating fixed price contracts with their project managers every two weeks. Just how toxic such a situation would be should be obvious. Managers need to understand the context of the job and determine if they're satisfied with the productivity of their employees. Agile is a development process not a contract pricing strategy. If anything proponents of "Agile" would be more hesitant to quote you a firm fixed price contract than "Waterfall" teams.
        4y ago
- lucumo 4y ago
  Is padding really cheating? I'd describe that as accounting for unforeseen setbacks and correcting for overenthusiastic optimism.
  - rightbyte 4y ago
    Padding estimates is fine. But not when you report actual worked time, which was what we did to make management happy with the burn down charts straightness. If you don't report actual time for the task, the excercise is useless. E.g. shift work time from a slower than estimated task to a faster, or "wait" if the task was done too quickly.
- watwut 4y ago
  Imo, padding estimates is not cheating. It is just doing estimation right. Teams that do not pad estimates literally always underestimate amount of time needed.
- JohnFen 4y ago
  > I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". I was a trained Scrum Master and I knew this very well.
  - ResearchCode 4y ago
    What's a trained "scrum master"? I thought the certs don't even have exams.
Kichererbsen 4y ago
Totally with you. But since I'm currently preparing to get certified for Scrum, I'd like to point out that all those things you mentioned above aren't really part of Scrum at all...
robertlagrant 4y ago
All the estimation stuff is only for your team, not for outside consumption. If you release it and care what people say about it, then that I don't think that's the methodology's fault.

kqr 4y ago

For the purposes of understanding the way people act, it is important to focus on what they believe to be the truth, not what the truth is. Software development is incredibly opaque by default (heck, even we don't know how far along we are, most of the time) so anything that improves that will be perceived as improved productivity. But even if it's not, sometimes progress reporting (however rough) is needed to synchronise with other parts of the organisation. It just needs to be put into a form that is useful (e.g. for agile projects "percent of plan delivered" is not a useful metric) and how it's going to be used should be explained to those producing it. Heck, optimal is if the people making software and the people they need to coordinate with can get together and jointly agree on what type of reporting is actually meaningful for both parties. Almost always, we're discussing vanity metrics though.

enkid 4y ago

Having predictability and observability is key to a business though, as higher level decision need to be made based on progress of the lower level teams.

kqr 4y ago
In my experience, if the business has a higher level decision that depends on the progress of a lower level team, the only working approach is for the manager in charge of that decision to sit down with a person in the lower level team and discuss the state of things. A metric compresses a very rich and nuanced opportunity into a false dichotomy.
danmaz74 4y ago
Yes, predictability is better for business, but business also needs to accept that there are limits to the amount of predictability you can achieve in software development, and trying to force too much process is only going to predictably increase delivery time. In my experience, working with high level estimates which you keep updating from time to time is the best compromise.
- kqr 4y ago
  There's no limit to predictability achievable in software development per se. You can have perfectly predictable software development -- if you know exactly what it is you're going to build. The trouble is -- as with any product development -- we don't know exactly what we are going to build because it depends on fickle market sentiments, new technology, etc. That is what sets the upper limit on predictability, and that can be controlled by high level decisions. (Unfortunately, increased predictability usually means decreased profitability.)
  - deleted 4y ago
    [deleted]
  - danmaz74 4y ago
    > You can have perfectly predictable software development -- if you know exactly what it is you're going to build. That's not enough - you can have pretty good predictability if you know exactly what you're going to build, and if you already built the same kind of thing with the same technologies/tools that you're going to use this time. Which is very often not the case: business very often wants new things that others don't already have, or the technologies/tools from previous times are now outdated (or believed so...).

fendy3002 4y ago

The problem is even scrum doesn't give the predictability and observability better than kanban. It's extremely hard to predict what we need to do in next 2 weeks and what we can achieve in next 2 weeks. At my current company, half, if not more, of the tickets come in mid-sprint. So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain amount of story points, then add / remove as the sprint is going.

throw3823423 4y ago
I have seen a very predictable scrum, but the tradeoffs with productivity were comical. In this very large corporation, most developers could do most of the tasks in their 2 week sprints in 3 days of actual work. But they don't know if they are going to get 3 days of actual work, or some other team is going to keep master broken for a week. Therefore, your typical sprint involves mostly fictional standup updates, as to make sure that, when things go more than a little too well, the shameful levels of sandbagging aren't visible in jira or in git. If you ask me, that level of predictability is a poor tradeoff, but hey, it's the same kind of organization that decides that SAFe scrum is a serious methodology.
- robertlagrant 4y ago
  SAfE is definitely a bad idea, but keeping master broken should be a "automated tests guard master" retro action.
  - gedy 4y ago
    These type of problems usually are not "actionable" with big legacy apps, poor coverage, etc.
    - robertlagrant 4y ago
      Someone who's not a technical junior needs to make it very clear that breakages will keep happening and support staff will need increasing if no one has the time to figure out a test harness or similar for the software in question. If people are literally blocked because someone else has broken master then they should be working on a test harness right now, in fact. That would actually be useful.

robertlagrant 4y ago

I think I'd pick any team, not just software, telling me when something will exist over them saying they're more efficient. Efficient isn't even a metric I'd understand in most cases, e.g. a plumber telling me the house will be done as efficiently as possible but I won't know when any particular room will be unavailable so I can't plan around that info.

alfons_foobar 4y ago
But isn't the problem exactly that, that oftentimes we cannot know in advance how long it will take to implement X?
- tharkun__ 4y ago
  I think your parent is trying to say that you won't hire the plumber that only tells you he will be efficient doing his job. But you will hire the plumber that tells you "if I don't find surprises behind the wall, this is a 2 hour job". And then he opens up the wall and finds old corroded iron piping he has to trace down to where it attaches to the main line and replace it all or else you won't get your new bathroom done at all. And that job takes more than 2 hours. You could also have said "well if that's the case can you poke some exploratory holes in the drywall please so I can get a better estimate" (aka a "spike").

Double_a_92 4y ago

I've seen many people complain about reviews and retrospectives in those threads... But they don't seem like a bad thing to me. The problem is if the sprint is too short. But if the review and retro are done e.g. once every month or so, it can be a good way to see what the other teams have been doing and get an overall picture of your software. And the retro can be a good opportunity to talk about any problems that you encountered, and maybe trigger a solution, or at least just vent about it.

re-thc 4y ago
The problem is nothing comes out of it. We run retros and there are action items and they go into a black hole. The higher ups do it to follow the process and not to fix the actual problems. It gets tiring after a while of time wasting.
watwut 4y ago
I do not want to talk about these problems again and again and again. I would like to see some improvements. First few times it works as a psychohygiene, but then it just becomes annoying. So teams stops talking about actual deep issues on those meetings and they are are creating an illusion of happiness.

s-lambert 4y ago

I don't see retrospectives being that much of a time-sink, it's a 30min/1hr meeting every 2 weeks. Even when I was on a kanban team they still had a fortnightly retrospective, it's useful to have a checkup occasionally.

hgsgm 4y ago
Every time someone hates Scrum they always complain about 2 week sprints, which are an insane choice (should be 4 weeks), that shows they aren't doing Scrum, they are micromanaging with "Scrum" as the excuse.
- Clubber 4y ago
  Yes, I don't know where the 2 week sprint thing came from, but everyone uses it as a default. I've tried to get it to 3 or 4 weeks but always get resistance. The main reason I think is the business wants their features NOW.
- ryathal 4y ago
  Going longer than two weeks for a sprint just makes the lies happen at different place. There are approximately 0 teams that can accurately state all the work they will need to do four weeks in advance, even two is a stretch. Planning and retro per sprint become a burden though, on less than two week sprints.
- icedchai 4y ago
  I currently work at a place that does 1 week sprints. It's bad.

darreninthenet 4y ago

This is just doing scrum badly... management break it by insisting the metrics etc are used as a reporting mechanism, they just cannot get away from "intensive control mode". The metrics are supposed to be for the team to use internally. But I do agree with the post - Kanban is way way better and you can include the scrum continuous improvement elements as well on a regular cycle.

Jochim 4y ago
> The metrics are supposed to be for the team to use internally. You've already pointed out that this is basically unheard of but I'm struggling to think of situations where scrum metrics have provided benefits that outweighed the cost of taking, and exposing them. My experience has been that most development teams intuitively recognise problems that might be revealed by these metrics. Is this not often the case?
- darreninthenet 4y ago
  This is where a decent scrum master or agile coach is valuable - fighting off the misuse of the metrics by external (to the team) management. The thing is with metrics is that they are hard to argue with, whereas intuition is a debatable opinion. Perhaps not everyone in the team agrees. Perhaps it's about showing interfering management or dependent teams where the issues lie. Perhaps the team doesn't realise how long a particular stage in their workflow is holding things up - I mean they know that stage is a problem but have they realised it's actually their biggest blocker to finishing work? Also depending on what you use to generate metrics - something like ActionableAgile that use Monte Carlo simulations against a few weeks worth of activities can show a team what their cycle time is, what items are in danger of blowing that and how long it's likely to finish just their current backlog (for example). As you say, in their worst case they tell teams what they already know and then again that's the value of a good SM or AC - finding out why nothing is being done about it (whilst beating away interfering managers).

DoingIsLearning 4y ago

>The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. Agree with everything _expect_ retros. I think the value of the retros is proportional to how senior the team is and to how seasoned managers are. But for me retros are extremely high value _if_ you have: - Teams that can look at problems head on and be civil addressing things without making it personal. - Managers that have a 'clear roadblocks' mindset and have a service-providing mindset towards the team. In this scenario you can really have high value retros, with continuous adjustments to workflow, processes, design, without continuously repeating the same mistakes or falling in the same pitfalls.

lucumo 4y ago
I found that retros tend to devolve into gripe sessions when the team isn't able to change its environment. Best to keep them focused on things they can actually change, and just to let them fix what they need instead of talking about it. Also, after an initial stabilisation period, teams need fewer and fewer changes. Talking about it every sprint gets really pointless and takes time away from the things they're good at and they're motivated to do.
- przemo_li 4y ago
  Proposing retro board be available 24/7 and retros be skipped if board is empty is good use of retro time. ;)
  - bluefirebrand 4y ago
    This sounds amazing. But I do wonder if it just encourages people not to bring up real problems so that they can skip a meeting. I think having the board up at all times is a great idea though. Just have to have some way to figure out "is it empty because things are fine or is it empty because no one cares anymore".
sodapopcan 4y ago
I've worked on a team that had amazing retros: lots of difficult discussions that resulted in change. We also made sure to discuss positive things too to ensure they keep happening. I think a lot of people miss this about retro. I also worked on a team with terrible retros. The "good" column would always be extremely long and was only full of platitudes, nothing of actual substance that was brought forward into the next week. If anything difficult came up, someone would say, "Ok, let's book a meeting to talk about this later". It was an extreme misunderstanding of the value of retros. Though everyone else seemed to enjoy them so that's arguably valuable? I dunno. Anyway, yes, lots has been said on this topic in the past. SCRUM is just Agile for stakeholders. There is the whole "SCRUM But" joke but I actually think a bunch of things in SCRUM are valuable BUT if something isn't working out, don't do it! I get the impression that lots of companies just do all the rituals "because SCRUM" and don't actually understand why they are doing them. Case in point, I was at a company that would always spend time story-pointing but no one ever looked at them. Not the teams and not the stakeholders.

ithkuil 4y ago

> Especially if nobody can actually quantitatively measure the loss of efficiency. Yet ironically they care and tout about their ability to measuring efficiency. An easy way to boost efficiency: hide inefficiency out from view!

gofreddygo 4y ago

> most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. we're in this exact phase - sacrificing efficiency, team morale and independence to make the boards look cleaner to "raise the bar" per se. We're a small efficient team in a massive org. Manager does a great job of not making stupid decisions, values people's time and is clear about the metrics the team gets evaluated on. somewhere along the way he's, missed the reality that clean user stories and tasks, complete with points down to hours and acceptance criteria can still be completely f$#king wrong compared to the actual work that needs to be done. Not because the people are idiots but because thats how most software work is. You find out when you actually start working on it. But if you mandate that you need a well cut plan before code gets written, you mostly get well written $hit. We just embarked on this journey which I can mostly predict the outcome of. sad, true.