10 ms·

The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-

by akudha 5y ago

The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted and quick. The only thing we religiously followed was daily, quick 15 min stand-ups. Everything else was flexible. My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. And retro - gawd, I hate those. There are all kinds of stupid shit (people using references from music, movies etc, trying to make it "fun" and "hip"). I can't bring other tasks into the sprint, even if I finished all my current tasks, without my manager's permission. And on and on. I was thinking the other day why this is so painful and awkward. I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. So he has to do all kinds of jugglery to appear competent to his bosses and not alienate the team at the same time. All of this could be avoided by treating the team as adults, instead of trying to "processify" or quantify everything. However hard we try, human beings can't be slotted neatly into buckets nor can they be precisely quantified. However hard we try, estimating software projects will never be an exact science.

afarrell 5y ago
> instead of trying to "processify" A cause of this problem is when people are worried about what happens when they say "erm, I don't know how to do this cleanly" and so they want the "how" to be defined far far in advance. Solving this requires a mix of A. Identifying those activities that will genuinely make people's lives easier if they have a process and designing those processes to be meaningful and low-burden. Those activities will vary based on team members individual peeves and affinities. B. Creating clear lines of communication for how and whom to ask for help. This often means more clear naming of responsibilities. C. Ensuring there is enough slack time for people to be able to help each other out. D. Creating trust in the team that asking for help won't lead people to question if you are fit to do your job. > quantify everything Many times, this is the https://en.wikipedia.org/wiki/McNamara_fallacy https://en.wikipedia.org/wiki/McNamara_fallacy
- lordnacho 5y ago
  Also goes hand in hand with Goodhart's Law.
jshmrsn 5y ago
We have sprint retros and generally find them valuable. I’m curious how one would even go about incorporating music and movies into a sprint retro? That does sound painful.
- CraneWorm 5y ago
  I think they mean when your retro board has a theme; I've seen various themes applied successfully i.e. sailboat:https://metroretro.io/templates/the-sailboat-retrospective https://metroretro.io/templates/the-sailboat-retrospective
  - david422 5y ago
    Is it just me or does this look great for a 2nd grade class.
    - khyryk 5y ago
      It sort of betrays how people think of tech nerds. :)
    - mk89 5y ago
      We do it at my company/in my team. It's OK, come on, it's not that bad. It's also a way for our team to get together and talk BS, have a little bit of fun etc.
    - datavirtue 5y ago
      Get on the call and suck your thumb to fit in.
    - ebiester 5y ago
      It depends on your team. I have teams that respond well to it. People like me, who work in metaphors and abstractions, respond well to it.
  - hnuser847 5y ago
    It's amazing how infantilized this industry has become during my short 10 year career. I'm so thankful I switched to product and don't have to deal with this BS anymore.
troupe 5y ago
> debating whether it is worth 5 points are 8 I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on. I think you are right that much of that is driven by managers looking for metrics, but unless they understand what the metrics mean it is pointless.
- erikwiffin 5y ago
  I think there's value in that debate (within reason) even as a developer. If Alice thinks a task is worth 5, and Bob thinks it's worth 8, then there's a good chance one of them knows something the other does not. Is Bob aware of some hidden complexity that bumps it up 3 points? Or is Alice familiar with a convenient library that solves exactly that complexity? Planning poker is a convenient time to get that knowledge out into the open. Again, this is all within reason, and if it takes 15 minutes on every ticket, the team should probably work on their communication skills.
  - seanhunter 5y ago
    > there's a good chance one of them knows something the other does not Or that the assignment of points is arbitrary and imprecise and that different people have different ways of making up numbers.
    - jhugo 5y ago
      Exactly this. It's probably not an accident that one of those numbers is half of 10 (and the number of fingers on one hand) – a common made-up number for everybody – and the other is 2^3 – a common made-up number for programmers.
      - erikwiffin 5y ago
        I've always done planning poker with the Fibonacci sequence - 1, 2, 3, 5, 8. The idea being that the more complicated the task, the harder it is to estimate accurately.
nickd2001 5y ago
" I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how to game the system to ensure their metrics were good. I cannot see how this can have done the employer any good. I've now moved jobs, to a place that's far more Kanban, and if mid-story we encounter bugs that need fixing, or opportunities to improve something, or something else useful that piques our fancy, then as long as the whole team agree and our overarching goals are being worked toward , we can work naturally, rather than rigidly.
- mk89 5y ago
  Interesting, I had a very similar experience in the past. I think we just were part of a software factory that is not necessarily bad, it's just a different approach to work. It's much more convenient for a manager to just apply "standard" principles (scrum, 2 weeks, story points, velocity, etc. like a mantra) rather than innovating at this risk of being wrong, difficult, etc. Too much bureaucracy is not good, maybe that was the purpose of this article. The more you have it, the more difficult it becomes to get out of it, to innovate, etc.
  - pempem 5y ago
    Agreed on the kind of religious adherence which can make the process feels a bit like..a staged show? Stifling instead of open discussion? "Metrics" though drive when something might be delivered which triggers marketing spend, hiring requirements and so on. It says "we're working on this now and that next" which drives all kinds of internal storytelling about priorities and cascades down (or up?) into quarterly calls. How do you do it otherwise without having ipod summers?
    - Jensson 5y ago
      You set up long term team based goals (OKR's, Objectives and Key Results) and then evaluate how well those goals were achieved. It isn't 100% accurate or fair, but neither are Scrum burndown charts.
comeonseriously 5y ago
Scrum is Agile, strictly enforced.
ta988 5y ago
A lot of places are looking for new people (even remotely), don't stay in a place that makes you miserable. You don't have to suffer for other peoples mismanagement.
g051051 5y ago
> My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. That was my last gig. The whole organization eventually just collapsed under the increasing load of being "Agile".
vannevar 5y ago
>Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. If you're not personally responsible for deadlines on the project, it could seem pointless. But the difference might mean pushing the commitment for a feature out two weeks, which in a commercial project could be a big deal. Planning is hard: you've got to try to estimate something with incomplete information, and then reconcile differing opinions. But it's definitely not pointless. Velocity is probably one of the most misunderstood aspects of scrum. It's a key metric for long-term planning, but it's not intended to be manageable. It's also unique to the team, and not intended to be compared between teams. Many managers are not used to a metric that they don't manage, and that causes a lot (maybe most) of the bad experiences people have with poorly practiced scrum.
ericb 5y ago
At my work, when one of us gets too into the details of pointing, estimation, or process we usually realize, stop, and say "sorry--I was being a Scrumbag"
robertlagrant 5y ago
> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. This is a thing that's pretty key to Scrum: velocity can't be used to compare teams. It is easy to misuse though. I would start every meeting I were in with "these points measures cannot be used to measure performance between teams."
- mindcrime 5y ago
  I find "velocity" to be almost completely useless, both in principle and in practice. It's not only useless for comparing teams, it's useless for comparing the same team over time if anything that affects "velocity" changes: the team composition, the length of the iterations, the nature of the tasks being worked on, etc. Now, how often have any of us worked on a project where at least one of those things didn't change, and sometimes fairly frequently? I mean, just the difference in an iteration with a couple of people on PTO, or a holiday or two intruding into it, will throw the numbers off. Now factor in all of the other fuzziness that's inherent in the process... yeah, no. Don't bother trying to calculate or track "velocity". You'd probably get better results from Tarot cards or animal entrails.
  - giantrobot 5y ago
    I too find velocity to be one of the dumbest aspects of Agile. It takes the stupid of story points and doubles down on uselessness and arbitrariness. Velocity in physical terms is an instantaneous measure. It's the same in Agile, you've done X things in Y time. But that ignores the context of those X tasks and the context of Y time. The X+1 task might turn out more difficult or have some other challenge that makes it take longer. Time keeps passing so at time Y+2 the velocity measurement is lower than before. Now all the PMs and other team members jump in demanding answers which now makes the task take even longer. As you mention, some span of time can see team members out or unavailable. So the velocity is "low" but rarely is that context captured or bubbled up the management chain. So your team has "low velocity" which ends up generating worthless meetings, bad reviews, or all sorts of problems.
bitwize 5y ago
> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. You've discovered the secret of Agile in the corporate workplace: that the key takeaways, as far as the enterprise is concerned, are not finding better ways to develop software and better customer-developer relations. It's all about trackability, measurement, and metrics, because everything is. Trackability and measurement enable key decision makers to make accurate budgeting and execution plans and there is literally nothing else for key decision makers. Therefore, it makes less of a difference what you output than that it was properly planned for, tracked, and measured and that it hits organizational KPIs. That's why nobody cares that Scrum is a giant productivity suck. Code could be written faster, but that's not writing it properly. Agile in the enterprise is a game of Mornington Crescent. The goal is not to foster the things advocated in the Agile Manifesto. It's to make it look like the company is fostering those things, while actually promoting the same Taylorist values corporations have always loved (and workers hated).
- mindcrime 5y ago
  Agile in the enterprise is a game of Mornington Crescent. That's probably the best description of "agile in the enterprise" I've ever read.
  - nivertech 5y ago
    Almost: "Interspersed with the turns is h̶u̶m̶o̶r̶o̶u̶s̶ 𝗯𝗼𝗿𝗶𝗻𝗴 discussion among the panelists and host regarding the rules and legality of each move, as well as the strategy the panelists are using. The actual aim of the g̶a̶m̶e̶ 𝗰𝗲𝗿𝗲𝗺𝗼𝗻𝘆 is to e̶n̶t̶e̶r̶t̶a̶i̶n̶ 𝘄𝗮𝘀𝘁𝗲 𝘁𝗶𝗺𝗲 𝗮𝗻𝗱 𝗺𝗶𝗰𝗿𝗼𝗺𝗮𝗻𝗮𝗴𝗲 the other participants and listeners with a̶m̶u̶s̶i̶n̶g̶ 𝗿𝗲𝗽𝗲𝘁𝗶𝘁𝗶𝘃𝗲 discussion of the fictional rules and strategies." https://en.wikipedia.org/wiki/Mornington_Crescent_(game) https://en.wikipedia.org/wiki/Mornington_Crescent_(game)
SkyPuncher 5y ago
> In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted and quick. The only thing we religiously followed was daily, quick 15 min stand-ups. Everything else was flexible. This is exactly how I've seen it run with success at several different companies (including how I run it). In my mind, the most important value of Scrum is having a cadence to give people reasonable timeframes to think in AND ensure that a variety of different conversations happen frequently enough (discovery, planning, prioritization, execution). ---- > And retro - gawd, I hate those. It sounds like you hate these because you aren't actually empowered to make meaningful change within your team. We've found retros are one of our most important rituals. They help us identify risks, process, and team issues; often while they're still small. We quickly work those in.
- fatnoah 5y ago
  When I ran Engineering for a startup, this is roughly how we did things as well. If a disagreement around pointing a story happened, we resolved it within seconds and usually just went with the larger size. It didn't really matter so much, since we weren't using velocity as a goal or something reported on a weekly basis. I did use it to roughly ballpark how many sprints it might take to deliver something, but that was as much story point math as I ever did and never used it to guarantee a date. I did have to fight a few battles with my CEO and other VPs around that, but, in the end, the results of mostly consistent and predicable progress with happier dev teams made those arguments moot. We also found retrospectives to be pretty useful and each team was encouraged to find what worked for them. The result was that we had 5 teams that had some agile/scrum process, but created mechanics that worked well for them.
  - SkyPuncher 5y ago
    > I did use it to roughly ballpark how many sprints it might take to deliver something, but that was as much story point math as I ever did and never used it to guarantee a date. This is basically how we use it. Typically, if we have a multi-sprint effort, we'll guarantee delivery in the last or second to last sprint. Anything before that and we're having conversations around scope and trade-offs we need to make to hit targets. I've had several engineers tell me their 1.5x to 2.0x as effective as their prior roles while having better WLB.
sunwooz 5y ago
Oh god, this perfectly describes the company I just quit. They went from using Trello, allowing us to choose what to work on, loosely setting story points and ... that was it. Then they decided they needed the metrics on everything, so they switched to JIRA, started doing retros, setting strict points on tasks(reprimanded in retros if you messed up), using burndown charts to reprimand even more, and giving the product manager the power to dictate what I work on and in what order. It went from being a great company to work at, to a company I ran away from. I have half a mind to send this thread over to them.
- loopz 5y ago
  No need. Abusers won't listen in the first place.
theonething 5y ago
> The only thing we religiously followed was daily, quick 15 min stand-ups. One of the worst parts of scrum in my opinion. Even if it's a "quick" 15 minutes (which in my experience it rarely ever is), the forced context switch ends up wasting more than 15 minutes of productive time every day.
tlarkworthy 5y ago
Funny, retros are the one thing I like. If you can get a team to honestly say what went well and what went bad, and the step that can be taken to improve, every two weeks, with some light follow up. In 6 - 12 months, you can turn a flaming wreck of a project into something that resembles best practice. I have do it as a consultant. I have taken a project on life support that they were gonna cancel, regardless of our performance, and resurrected it so hard they actually decided to keep it. We changed their minds The most effective tool was retros. I dislike agile in all other aspects, and do not use story points. Retros are the best bit! It's the core part of the learning loop. I learnt retros from Google. Big tech does retros. Its honestly magic when done well.
- gampleman 5y ago
  Retros are great iff there is team empowered to actually meaningfully change stuff. I've been in places where everyone agrees that something sucks but there is no actual way to change it. Then retros turn into an impotent bitching session... no thanks.
mmcnl 5y ago
Presenting scrum metrics to management is definitely not scrum. That's the opposite of scrum.

by akudha 5y ago

afarrell 5y ago

> instead of trying to "processify" A cause of this problem is when people are worried about what happens when they say "erm, I don't know how to do this cleanly" and so they want the "how" to be defined far far in advance. Solving this requires a mix of A. Identifying those activities that will genuinely make people's lives easier if they have a process and designing those processes to be meaningful and low-burden. Those activities will vary based on team members individual peeves and affinities. B. Creating clear lines of communication for how and whom to ask for help. This often means more clear naming of responsibilities. C. Ensuring there is enough slack time for people to be able to help each other out. D. Creating trust in the team that asking for help won't lead people to question if you are fit to do your job. > quantify everything Many times, this is the https://en.wikipedia.org/wiki/McNamara_fallacy https://en.wikipedia.org/wiki/McNamara_fallacy

lordnacho 5y ago
Also goes hand in hand with Goodhart's Law.

jshmrsn 5y ago

We have sprint retros and generally find them valuable. I’m curious how one would even go about incorporating music and movies into a sprint retro? That does sound painful.

CraneWorm 5y ago
I think they mean when your retro board has a theme; I've seen various themes applied successfully i.e. sailboat:https://metroretro.io/templates/the-sailboat-retrospective https://metroretro.io/templates/the-sailboat-retrospective
- david422 5y ago
  Is it just me or does this look great for a 2nd grade class.
  - khyryk 5y ago
    It sort of betrays how people think of tech nerds. :)
  - mk89 5y ago
    We do it at my company/in my team. It's OK, come on, it's not that bad. It's also a way for our team to get together and talk BS, have a little bit of fun etc.
  - datavirtue 5y ago
    Get on the call and suck your thumb to fit in.
  - ebiester 5y ago
    It depends on your team. I have teams that respond well to it. People like me, who work in metaphors and abstractions, respond well to it.
- hnuser847 5y ago
  It's amazing how infantilized this industry has become during my short 10 year career. I'm so thankful I switched to product and don't have to deal with this BS anymore.

troupe 5y ago

> debating whether it is worth 5 points are 8 I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on. I think you are right that much of that is driven by managers looking for metrics, but unless they understand what the metrics mean it is pointless.

erikwiffin 5y ago
I think there's value in that debate (within reason) even as a developer. If Alice thinks a task is worth 5, and Bob thinks it's worth 8, then there's a good chance one of them knows something the other does not. Is Bob aware of some hidden complexity that bumps it up 3 points? Or is Alice familiar with a convenient library that solves exactly that complexity? Planning poker is a convenient time to get that knowledge out into the open. Again, this is all within reason, and if it takes 15 minutes on every ticket, the team should probably work on their communication skills.
- seanhunter 5y ago
  > there's a good chance one of them knows something the other does not Or that the assignment of points is arbitrary and imprecise and that different people have different ways of making up numbers.
  - jhugo 5y ago
    Exactly this. It's probably not an accident that one of those numbers is half of 10 (and the number of fingers on one hand) – a common made-up number for everybody – and the other is 2^3 – a common made-up number for programmers.
    - erikwiffin 5y ago
      I've always done planning poker with the Fibonacci sequence - 1, 2, 3, 5, 8. The idea being that the more complicated the task, the harder it is to estimate accurately.

nickd2001 5y ago

" I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how to game the system to ensure their metrics were good. I cannot see how this can have done the employer any good. I've now moved jobs, to a place that's far more Kanban, and if mid-story we encounter bugs that need fixing, or opportunities to improve something, or something else useful that piques our fancy, then as long as the whole team agree and our overarching goals are being worked toward , we can work naturally, rather than rigidly.

mk89 5y ago
Interesting, I had a very similar experience in the past. I think we just were part of a software factory that is not necessarily bad, it's just a different approach to work. It's much more convenient for a manager to just apply "standard" principles (scrum, 2 weeks, story points, velocity, etc. like a mantra) rather than innovating at this risk of being wrong, difficult, etc. Too much bureaucracy is not good, maybe that was the purpose of this article. The more you have it, the more difficult it becomes to get out of it, to innovate, etc.
- pempem 5y ago
  Agreed on the kind of religious adherence which can make the process feels a bit like..a staged show? Stifling instead of open discussion? "Metrics" though drive when something might be delivered which triggers marketing spend, hiring requirements and so on. It says "we're working on this now and that next" which drives all kinds of internal storytelling about priorities and cascades down (or up?) into quarterly calls. How do you do it otherwise without having ipod summers?
  - Jensson 5y ago
    You set up long term team based goals (OKR's, Objectives and Key Results) and then evaluate how well those goals were achieved. It isn't 100% accurate or fair, but neither are Scrum burndown charts.

comeonseriously 5y ago

Scrum is Agile, strictly enforced.

ta988 5y ago

A lot of places are looking for new people (even remotely), don't stay in a place that makes you miserable. You don't have to suffer for other peoples mismanagement.

g051051 5y ago

> My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. That was my last gig. The whole organization eventually just collapsed under the increasing load of being "Agile".

vannevar 5y ago

>Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. If you're not personally responsible for deadlines on the project, it could seem pointless. But the difference might mean pushing the commitment for a feature out two weeks, which in a commercial project could be a big deal. Planning is hard: you've got to try to estimate something with incomplete information, and then reconcile differing opinions. But it's definitely not pointless. Velocity is probably one of the most misunderstood aspects of scrum. It's a key metric for long-term planning, but it's not intended to be manageable. It's also unique to the team, and not intended to be compared between teams. Many managers are not used to a metric that they don't manage, and that causes a lot (maybe most) of the bad experiences people have with poorly practiced scrum.

ericb 5y ago

At my work, when one of us gets too into the details of pointing, estimation, or process we usually realize, stop, and say "sorry--I was being a Scrumbag"

robertlagrant 5y ago

> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. This is a thing that's pretty key to Scrum: velocity can't be used to compare teams. It is easy to misuse though. I would start every meeting I were in with "these points measures cannot be used to measure performance between teams."

mindcrime 5y ago
I find "velocity" to be almost completely useless, both in principle and in practice. It's not only useless for comparing teams, it's useless for comparing the same team over time if anything that affects "velocity" changes: the team composition, the length of the iterations, the nature of the tasks being worked on, etc. Now, how often have any of us worked on a project where at least one of those things didn't change, and sometimes fairly frequently? I mean, just the difference in an iteration with a couple of people on PTO, or a holiday or two intruding into it, will throw the numbers off. Now factor in all of the other fuzziness that's inherent in the process... yeah, no. Don't bother trying to calculate or track "velocity". You'd probably get better results from Tarot cards or animal entrails.
- giantrobot 5y ago
  I too find velocity to be one of the dumbest aspects of Agile. It takes the stupid of story points and doubles down on uselessness and arbitrariness. Velocity in physical terms is an instantaneous measure. It's the same in Agile, you've done X things in Y time. But that ignores the context of those X tasks and the context of Y time. The X+1 task might turn out more difficult or have some other challenge that makes it take longer. Time keeps passing so at time Y+2 the velocity measurement is lower than before. Now all the PMs and other team members jump in demanding answers which now makes the task take even longer. As you mention, some span of time can see team members out or unavailable. So the velocity is "low" but rarely is that context captured or bubbled up the management chain. So your team has "low velocity" which ends up generating worthless meetings, bad reviews, or all sorts of problems.

bitwize 5y ago

> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. You've discovered the secret of Agile in the corporate workplace: that the key takeaways, as far as the enterprise is concerned, are not finding better ways to develop software and better customer-developer relations. It's all about trackability, measurement, and metrics, because everything is. Trackability and measurement enable key decision makers to make accurate budgeting and execution plans and there is literally nothing else for key decision makers. Therefore, it makes less of a difference what you output than that it was properly planned for, tracked, and measured and that it hits organizational KPIs. That's why nobody cares that Scrum is a giant productivity suck. Code could be written faster, but that's not writing it properly. Agile in the enterprise is a game of Mornington Crescent. The goal is not to foster the things advocated in the Agile Manifesto. It's to make it look like the company is fostering those things, while actually promoting the same Taylorist values corporations have always loved (and workers hated).

mindcrime 5y ago
Agile in the enterprise is a game of Mornington Crescent. That's probably the best description of "agile in the enterprise" I've ever read.
- nivertech 5y ago
  Almost: "Interspersed with the turns is h̶u̶m̶o̶r̶o̶u̶s̶ 𝗯𝗼𝗿𝗶𝗻𝗴 discussion among the panelists and host regarding the rules and legality of each move, as well as the strategy the panelists are using. The actual aim of the g̶a̶m̶e̶ 𝗰𝗲𝗿𝗲𝗺𝗼𝗻𝘆 is to e̶n̶t̶e̶r̶t̶a̶i̶n̶ 𝘄𝗮𝘀𝘁𝗲 𝘁𝗶𝗺𝗲 𝗮𝗻𝗱 𝗺𝗶𝗰𝗿𝗼𝗺𝗮𝗻𝗮𝗴𝗲 the other participants and listeners with a̶m̶u̶s̶i̶n̶g̶ 𝗿𝗲𝗽𝗲𝘁𝗶𝘁𝗶𝘃𝗲 discussion of the fictional rules and strategies." https://en.wikipedia.org/wiki/Mornington_Crescent_(game) https://en.wikipedia.org/wiki/Mornington_Crescent_(game)

SkyPuncher 5y ago

> In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted and quick. The only thing we religiously followed was daily, quick 15 min stand-ups. Everything else was flexible. This is exactly how I've seen it run with success at several different companies (including how I run it). In my mind, the most important value of Scrum is having a cadence to give people reasonable timeframes to think in AND ensure that a variety of different conversations happen frequently enough (discovery, planning, prioritization, execution). ---- > And retro - gawd, I hate those. It sounds like you hate these because you aren't actually empowered to make meaningful change within your team. We've found retros are one of our most important rituals. They help us identify risks, process, and team issues; often while they're still small. We quickly work those in.

fatnoah 5y ago
When I ran Engineering for a startup, this is roughly how we did things as well. If a disagreement around pointing a story happened, we resolved it within seconds and usually just went with the larger size. It didn't really matter so much, since we weren't using velocity as a goal or something reported on a weekly basis. I did use it to roughly ballpark how many sprints it might take to deliver something, but that was as much story point math as I ever did and never used it to guarantee a date. I did have to fight a few battles with my CEO and other VPs around that, but, in the end, the results of mostly consistent and predicable progress with happier dev teams made those arguments moot. We also found retrospectives to be pretty useful and each team was encouraged to find what worked for them. The result was that we had 5 teams that had some agile/scrum process, but created mechanics that worked well for them.
- SkyPuncher 5y ago
  > I did use it to roughly ballpark how many sprints it might take to deliver something, but that was as much story point math as I ever did and never used it to guarantee a date. This is basically how we use it. Typically, if we have a multi-sprint effort, we'll guarantee delivery in the last or second to last sprint. Anything before that and we're having conversations around scope and trade-offs we need to make to hit targets. I've had several engineers tell me their 1.5x to 2.0x as effective as their prior roles while having better WLB.

sunwooz 5y ago

Oh god, this perfectly describes the company I just quit. They went from using Trello, allowing us to choose what to work on, loosely setting story points and ... that was it. Then they decided they needed the metrics on everything, so they switched to JIRA, started doing retros, setting strict points on tasks(reprimanded in retros if you messed up), using burndown charts to reprimand even more, and giving the product manager the power to dictate what I work on and in what order. It went from being a great company to work at, to a company I ran away from. I have half a mind to send this thread over to them.

loopz 5y ago
No need. Abusers won't listen in the first place.

theonething 5y ago

> The only thing we religiously followed was daily, quick 15 min stand-ups. One of the worst parts of scrum in my opinion. Even if it's a "quick" 15 minutes (which in my experience it rarely ever is), the forced context switch ends up wasting more than 15 minutes of productive time every day.

tlarkworthy 5y ago

Funny, retros are the one thing I like. If you can get a team to honestly say what went well and what went bad, and the step that can be taken to improve, every two weeks, with some light follow up. In 6 - 12 months, you can turn a flaming wreck of a project into something that resembles best practice. I have do it as a consultant. I have taken a project on life support that they were gonna cancel, regardless of our performance, and resurrected it so hard they actually decided to keep it. We changed their minds The most effective tool was retros. I dislike agile in all other aspects, and do not use story points. Retros are the best bit! It's the core part of the learning loop. I learnt retros from Google. Big tech does retros. Its honestly magic when done well.

gampleman 5y ago
Retros are great iff there is team empowered to actually meaningfully change stuff. I've been in places where everyone agrees that something sucks but there is no actual way to change it. Then retros turn into an impotent bitching session... no thanks.

mmcnl 5y ago

Presenting scrum metrics to management is definitely not scrum. That's the opposite of scrum.