10 ms·

What in Scrum is about keeping managers happy?

by LeFantome 2y ago

pan69 2y ago
Story points, velocity, burn down charts, shit like that.
- wild_egg 2y ago
  None of those things are part of scrum as described by the actual guide
  - RussianCow 2y ago
    But nobody follows the actual guide so it doesn't really matter.
wsc981 2y ago
Some things that come to mind: - burn-down / velocity charts - retrospectives - poker sessions - daily stand-ups - user stories and related tickets (eg in JIRA) There’s probably more ... Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff. As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we don’t deal with any of the above shit. Which of course is sure to change as the company grows, as that seems to happen often. Our current way of working (remote company, 4 people): - 2 calls a week, which tend to last about an hour. - We discuss work for upcoming week or future stuff. - We try to deliver every week on whatever was agreed upon at start of week. Actually, previous company I worked at, was a bit bigger (35 people), but also very little rituals, at least for devs. There was a support department that did the JIRA related stuff. And we had like 2 day-long meetings every year to discuss personal goals/work for next half year. But afterwards just a short weekly meeting for team (sometimes lasting only 10 minutes), no stand-ups and such.
- jghn 2y ago
  I've been a dev, and I've been an EM. The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship. Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to have them requested by my teams. Who knew.
  - rpcope1 2y ago
    As a developer, I find retros most useful when EMs (and probably PMs, depends on how things are configured organizationally) aren't present, as it should give a chance to talk freely about challenges you or the team face, which often are organizational in nature and may involve one's management chain. My current role doesn't adhere to this, and it makes retro often really painful.
    - jghn 2y ago
      I would agree with you. I never want my manager there. As an EM, I never want to be there. And yet, as the years go by, when I have an EM role I find my presence is requested. Again, who knew?
      - Leherenn 2y ago
        I don't know, at least for my current team a lot of the stuff we complain about in the retro is beyond the team level: coordination between teams, infrastructure issues, ... The intra team issues are usually talked about before (e.g. during standup, or just asynchronously). If the EM is not there, those are not actionable. What we try to do is: do the retro by ourselves, and invite the EM at the end of there is stuff for them. Usually they are not available though...
  - meowfly 2y ago
    Retros all too often focus on the last thing that happened and risk turning into a complaint session. I've told my team anyone is welcome to ask for a retro whenever for any reason, but we don't make them recurring meetings because there is too much of a temptation to find something wrong to fill the time.
twunde 2y ago
Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted. A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent on these ceremonies (sprint planning 1 hr, sprint retro 1 hour, daily standup 15-30 minutes. Plus whatever prep is needed and the interruption time.) For many companies this is a 20% or more overhead that's mainly busywork because you still need the additional meetings to understand what you're working on.
- gedy 2y ago
  This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give feedback was in Sprint demos, and the beginning of planning meetings to answer any questions on upcoming stories. At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.
  - ta_1138 2y ago
    But Managers as the center of the scrum is how many, many tech companies the outside world wouldn't call crappy run things. They also use Jira, mostly because they want reports that let people two or three levels up think they have any control over anything. One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another. In practice, I don't think I've seen scrum run without a manager in standup, ever.
everdrive 2y ago
Without a lot of the project reports, the manager would honestly just have no idea what's going on. I recently moved into management, and one of the challenges I'm trying to balance is how to be aware of my team's progress without wasting their time or being a bottleneck for them. It's a legitimate problem which is often tackled poorly.
- skydhash 2y ago
  You can just talk to them. No need to set a ritual around it. Most professionals know about expectations and the team’s need to deliver.
  - everdrive 2y ago
    That's what I'm doing currently. We're a small team, and I'm a technical manager.
- laboratorymice 2y ago
  regardless of "process", work items should be tracked (in the problem solving record for our future selves sense, not time keeping sense), so you can follow those. If you're a non-technical manager, then either a) the implementation goes super smoothly and the estimate the dev team initially gave you is all the progress update you need, or b) it doesn't go super-smoothly and you should be involved in any discussions that arise. If you find yourself asking "when is it ready?" you've likely gone astray.
- randomdata 2y ago
  At least in the case of software development, which seems to be what Scrum is targeted at, you get the project reports for free by way of the commit log. That said, the 12 Principles of the Agile Manifesto offers another solution: Get rid of management entirely. It states that developers are best to work with the rest of the business collaboratively. Which is the irony of Scrum claiming to be Agile: Only management wants to use it, defying Agile to its fundamental core.
dartos 2y ago
Burn down charts, team velocity, and story points. They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.
- PaulHoule 2y ago
  There is nothing wrong with burndown charts but story points and team velocity are poison. The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc. See also https://en.wikipedia.org/wiki/Function_point https://en.wikipedia.org/wiki/Function_point Which is also a kind of development “funny money” but which have a somewhat rigorous method to arrive at estimates.
  - rerdavies 2y ago
    Agreed. Team velocity is a poison number. But entirely necessary in order to provide a data-driven approach to converting story points into time predictions (with appropriate disclaimer of risk) that people outside the team need. Data driven! How could that possibly be a bad thing? Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion. :-P But actually seriously. Nobody needs to know that number.
- rerdavies 2y ago
  Right. So you don't do that. No development process ever has provided bulletproof predictability. Your job as a project manager is not to provide bullet-proof predictions; it's to manage risk, and expectations, and make sure that development work is correctly prioritized. And of course to keep your development team protected from external insanity, because happy, stress free development teams are productive development teams. (But that's a separate issue). Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?
_heimdall 2y ago
I don't know if this is properly part of scrum, but it is how I've seen it implemented on every team I've been on where scrum was implemented. Sprints end with some kind of demo, retrospective, and sprint planning designed almost entirely to keep PMs and managers in the loop and happy. Reports are generated, spreadsheets with a few quarters worth of tasks are updated, and PMs or managers get to run that further up the chain, presumably to make it clear that great progress is being made under their supervision and well run scrum methodology.
- lo_fye 2y ago
  There are no PMs in actual Scrum. Scrum Teams are self-managing, so there's no need for a PM. There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that." In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key. When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic. When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
  - _heimdall 2y ago
    I could have been more clear there, "PM" has many different meanings these days. I've never been on a team using scrum that didn't have a project manager or product manager as part of scrum (or both). Most often they have been my scrum leader. Scrum is supposed to be self-guided, but I have never seen it implemented on a team of any scale. I also wouldn't expect a team without PMs, whether that's project managers or product managers, to be very effective. Someone needs to be focused on keeping the project moving, and often the skills needed for a scrum leader/master overlap greatly with project managers. Someone also needs to be focused on the product and how the team's efforts fit into the longer term product goals. If that isn't anyone with a PM title it will be someone else playing that role with everything but the title.
pie420 2y ago
they give managers visibility, deliverables, stuff to fill their calendars with, and automates their job into easy, if inefficient daily meetings.

What in Scrum is about keeping managers happy?

pan69 2y ago

Story points, velocity, burn down charts, shit like that.

wild_egg 2y ago
None of those things are part of scrum as described by the actual guide
- RussianCow 2y ago
  But nobody follows the actual guide so it doesn't really matter.

wsc981 2y ago

Some things that come to mind: - burn-down / velocity charts - retrospectives - poker sessions - daily stand-ups - user stories and related tickets (eg in JIRA) There’s probably more ... Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff. As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we don’t deal with any of the above shit. Which of course is sure to change as the company grows, as that seems to happen often. Our current way of working (remote company, 4 people): - 2 calls a week, which tend to last about an hour. - We discuss work for upcoming week or future stuff. - We try to deliver every week on whatever was agreed upon at start of week. Actually, previous company I worked at, was a bit bigger (35 people), but also very little rituals, at least for devs. There was a support department that did the JIRA related stuff. And we had like 2 day-long meetings every year to discuss personal goals/work for next half year. But afterwards just a short weekly meeting for team (sometimes lasting only 10 minutes), no stand-ups and such.

jghn 2y ago
I've been a dev, and I've been an EM. The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship. Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to have them requested by my teams. Who knew.
- rpcope1 2y ago
  As a developer, I find retros most useful when EMs (and probably PMs, depends on how things are configured organizationally) aren't present, as it should give a chance to talk freely about challenges you or the team face, which often are organizational in nature and may involve one's management chain. My current role doesn't adhere to this, and it makes retro often really painful.
  - jghn 2y ago
    I would agree with you. I never want my manager there. As an EM, I never want to be there. And yet, as the years go by, when I have an EM role I find my presence is requested. Again, who knew?
    - Leherenn 2y ago
      I don't know, at least for my current team a lot of the stuff we complain about in the retro is beyond the team level: coordination between teams, infrastructure issues, ... The intra team issues are usually talked about before (e.g. during standup, or just asynchronously). If the EM is not there, those are not actionable. What we try to do is: do the retro by ourselves, and invite the EM at the end of there is stuff for them. Usually they are not available though...
- meowfly 2y ago
  Retros all too often focus on the last thing that happened and risk turning into a complaint session. I've told my team anyone is welcome to ask for a retro whenever for any reason, but we don't make them recurring meetings because there is too much of a temptation to find something wrong to fill the time.

twunde 2y ago

Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted. A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent on these ceremonies (sprint planning 1 hr, sprint retro 1 hour, daily standup 15-30 minutes. Plus whatever prep is needed and the interruption time.) For many companies this is a 20% or more overhead that's mainly busywork because you still need the additional meetings to understand what you're working on.

gedy 2y ago
This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give feedback was in Sprint demos, and the beginning of planning meetings to answer any questions on upcoming stories. At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.
- ta_1138 2y ago
  But Managers as the center of the scrum is how many, many tech companies the outside world wouldn't call crappy run things. They also use Jira, mostly because they want reports that let people two or three levels up think they have any control over anything. One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another. In practice, I don't think I've seen scrum run without a manager in standup, ever.

everdrive 2y ago

Without a lot of the project reports, the manager would honestly just have no idea what's going on. I recently moved into management, and one of the challenges I'm trying to balance is how to be aware of my team's progress without wasting their time or being a bottleneck for them. It's a legitimate problem which is often tackled poorly.

skydhash 2y ago
You can just talk to them. No need to set a ritual around it. Most professionals know about expectations and the team’s need to deliver.
- everdrive 2y ago
  That's what I'm doing currently. We're a small team, and I'm a technical manager.
laboratorymice 2y ago
regardless of "process", work items should be tracked (in the problem solving record for our future selves sense, not time keeping sense), so you can follow those. If you're a non-technical manager, then either a) the implementation goes super smoothly and the estimate the dev team initially gave you is all the progress update you need, or b) it doesn't go super-smoothly and you should be involved in any discussions that arise. If you find yourself asking "when is it ready?" you've likely gone astray.
randomdata 2y ago
At least in the case of software development, which seems to be what Scrum is targeted at, you get the project reports for free by way of the commit log. That said, the 12 Principles of the Agile Manifesto offers another solution: Get rid of management entirely. It states that developers are best to work with the rest of the business collaboratively. Which is the irony of Scrum claiming to be Agile: Only management wants to use it, defying Agile to its fundamental core.

dartos 2y ago

Burn down charts, team velocity, and story points. They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.

PaulHoule 2y ago
There is nothing wrong with burndown charts but story points and team velocity are poison. The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc. See also https://en.wikipedia.org/wiki/Function_point https://en.wikipedia.org/wiki/Function_point Which is also a kind of development “funny money” but which have a somewhat rigorous method to arrive at estimates.
- rerdavies 2y ago
  Agreed. Team velocity is a poison number. But entirely necessary in order to provide a data-driven approach to converting story points into time predictions (with appropriate disclaimer of risk) that people outside the team need. Data driven! How could that possibly be a bad thing? Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion. :-P But actually seriously. Nobody needs to know that number.
rerdavies 2y ago
Right. So you don't do that. No development process ever has provided bulletproof predictability. Your job as a project manager is not to provide bullet-proof predictions; it's to manage risk, and expectations, and make sure that development work is correctly prioritized. And of course to keep your development team protected from external insanity, because happy, stress free development teams are productive development teams. (But that's a separate issue). Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?

_heimdall 2y ago

I don't know if this is properly part of scrum, but it is how I've seen it implemented on every team I've been on where scrum was implemented. Sprints end with some kind of demo, retrospective, and sprint planning designed almost entirely to keep PMs and managers in the loop and happy. Reports are generated, spreadsheets with a few quarters worth of tasks are updated, and PMs or managers get to run that further up the chain, presumably to make it clear that great progress is being made under their supervision and well run scrum methodology.

lo_fye 2y ago
There are no PMs in actual Scrum. Scrum Teams are self-managing, so there's no need for a PM. There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that." In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key. When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic. When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
- _heimdall 2y ago
  I could have been more clear there, "PM" has many different meanings these days. I've never been on a team using scrum that didn't have a project manager or product manager as part of scrum (or both). Most often they have been my scrum leader. Scrum is supposed to be self-guided, but I have never seen it implemented on a team of any scale. I also wouldn't expect a team without PMs, whether that's project managers or product managers, to be very effective. Someone needs to be focused on keeping the project moving, and often the skills needed for a scrum leader/master overlap greatly with project managers. Someone also needs to be focused on the product and how the team's efforts fit into the longer term product goals. If that isn't anyone with a PM title it will be someone else playing that role with everything but the title.

pie420 2y ago

they give managers visibility, deliverables, stuff to fill their calendars with, and automates their job into easy, if inefficient daily meetings.