4 ms·

What’s so funny to me is what you’re describing is the nightmare that’s become scrum as opposed to actual agility. Agile is about ditching managers, bureaucracy

What’s so funny to me is what you’re describing is the nightmare that’s become scrum as opposed to actual agility. Agile is about ditching managers, bureaucracy, and estimates in favor of empowering the team itself. Agility is just what it says: a philosophy of flexibility and adaptiveness. Heirarchies, heavy processes, etc are by definition inflexible. They are not agile. You do not do agile. You are agile. You are agile because your company has a culture that is agile and you cannot achieve that unless the company is structured to be flexible. I think actual agility is really, really a great way to build software efficiently... but unfortunately most programmers will only experience the cargo cult forced upon them by certified scrum masters... and this is just as bad, perhaps worse, than old fashioned waterfall. More than anything, working in an agile environment is a very pleasant thing to do from a human standpoint. But most companies are incapable of the kind of equality and empowerment necessary to achieve agility, so they will force the terrible cargo cult version upon us.

Viliam1234 6y ago
> Agile is about ditching managers, bureaucracy, and estimates in favor of empowering the team itself. Scrum (as intended, not as actually done in most companies) is in essence a set of rules to prevent things from falling apart after you have ditched the managers: * know what you want to achieve during this month -- planning for longer time is unrealistic, weekly planning is micromanagement; * at the end of the month, make a demo of new features -- make sure that all pieces fit together, and get feedback whether this is actually what the customer wanted; * reflect on what happened during this month and why -- this is the moment to speak freely, complain, and propose changes (for example, this is the occassion when the developers could collectively decide to stop using Jira); * decide where to go during the next month -- together with the customer: the customer decides "what first", developers decide "how fast"; * make sure your colleagues know what you do and whether you need help -- this shouldn't take more than 3 minutes a day. If your sprints are weekly, you are doing it wrong. If you don't make a demo, you are doing it wrong. First, with continuous integration, deploying the demo should be trivial. Second, if you don't show the demo to the customer, who is giving you feedback on your progress? (Nobody? Management?) If you skip the retrospective, or if you don't feel free to speak openly during the retrospective, you are doing it wrong. If you don't have an idea what to do next, and what is important for the customer, you are doing it wrong. If management gives you deadline, you are doing it wrong. If your daily standup takes more than three minutes, you are doing it wrong. (For anything that requires more time, you should arrange a separate meeting, for only the people involved, not the whole team. Note that the "separate meeting" could still be like five or ten minutes long.) So much for the dream. Now here is what actually happens: in your company, the managers have the power, and they are not going to fire themselves. So instead, they will impose on you some kind of management-driven pseudo-Scrum, which looks like this: The sprints are short, because that gives the managers greater feeling of control. You don't talk to the the actual customer, and the customer doesn't see your product before it is officially delivered; the managers acting as middlemen is how they justify their jobs. There is no retrospective, because this is the first and the last time in history when management decides that something is a waste of time. You have sprint planning, but you also have deadlines, so your choices are often limited to "do X this sprint and Y next sprint, or do Y this sprint and X next sprint". The daily, instead of team members synchronizing with each other, becomes team members reporting to the manager. You get Jira, which is set up according to the manager's wishes. This is not a coincidence. The managers insist it needs to be done this way, because they want to protect their jobs. The same thing would happen with any other methodology.
- vesinisa 6y ago
  > for example, this is the occassion when the developers could collectively decide to stop using Jira That's the gold standard! You know you are doing fake agile when the team is not allowed to decide stop using Jira. In all seriousness, thanks - very valued insights! I did not even know those were the original purposes of the Scrum ceremonies, having only ever worked witn almost exactly the kind of pseudo-Scrum you describe.
  - Too 6y ago
    Perfect litmus test indeed! I worked in one place where scrum master - the person explicitly assigned to protect the team - was the one who most loudly imposed that the company configured Jira shall be used. Despite this being brought up as a PITA every retrospective. This is the moment you know you are doing fake Agile and your scrummaster is just the managers puppet in disguise to spy on the team.
    - Viliam1234 6y ago
      It is difficult for the Scrum Master to be impartial in a situation where the management ultimately decides who will be the Scrum Master and whether Scrum will be used at all. I am not sure what would be the right solution. One possibility is to fire the management, or never even hire them at first place -- if you want to have a software company that uses Scrum, do it from start. Another possibility is to have a Scrum Master with strong political skils... which more or less means, it cannot be a former developer. Probably the fatal mistake is having too many managers in the company. At that moment, it is practically guaranteed that they will try to interfere with everything. They have to, because that is how they protect their own jobs. And they will hire more managers, because that is one way to get higher on the company ladder (hire more people into positions below you). And at that moment, everything is doomed, because now the company serves the managers instead of the other way round. I guess this means that Scrum can work as intended only in small companies. Where the Scrum Master is not below several layers of management, but on the same level as the few managers, right below the company owner.
- blabitty 6y ago
vesinisa 6y ago
Couldn't agree more. Just quit my job of last six years the previous week. I really liked the team and the product. We had a very informal development process - we all agreed it was agile but not through following any formal process (Scrum or such). We still had retros and dailies. Planning was done by managers explaining a feature they'd like us to do, and the team then doing the planning, design and implementation. More processes and e.g. recurring meetings were erected and torn down based on the team's actual needs alone. If someone wanted an estimate, we'd give it, but we were not doing continuos estimation just for the sake of estimation itself, like in Scrum. Felt like the process served us, rather than us serving a process. If you'd taken a look at the Agile manifesto, we were ticking pretty much all the boxes: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html Then 1.5 years ago, company decided to roll out whole IT department wide SAFe, which is basically Scrum but on a whole organization level, and hence even more bureaucratic and with one additional level of mega-iterations added on top of Scrum's sprints. Suddenly, our team is assigned a Scrum master and we no longer even get to speak directly with the managers who previously negotiated new features with us. Instead, everything has to go through multiple levels of prioritization and broken telephones of new SAFe intermediaries. We started attending 2-3 new mandatory processes / recurring meetings, meaning time spent in inefficient boring meetings went up significantly. We had to also start a much more stringent ticketing system regime, including having to estimate ALL work. Despite multiple requests from Scrum master and managers, nobody was ever able to explain why estimating absolutely everything - even when nobody had even asked for an estimate - helped with anything. It was seemingly taken as a religious thesis that it was just the right thing to do. Soon, the team was paralyzed. Even simple features became harder and harder to develop. Despite the massive effort spent on estimating even the most trivial of tasks, the big picture was forgotten about because larger feature-level ballpark estimates were no longer acceptable, and hence unimportant. On a company level, the business managers that previously talked directly to us just basically quit working with the IT department because the SAFe process was such a beast to contend. It was easiest for them to just stop asking for new digital product features, and focus on non-IT projects instead. I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way - Scrum consultants love to gloat when some metric improves, but if things go south the org has only itself to blame for failing to correctly convert to their favorite flavor of True Agile System™. My experience was however seeing an Agile team (as expressed by the Agile manifesto) turn into a Monty Python parody of agile software development just by being forced to submit to these "fake agile" heavy processes and hierarchies.
masterphilo 6y ago
> But most companies are incapable of the kind of equality and empowerment necessary to achieve agility, so they will force the terrible cargo cult version upon us. I would argue that most companies cannot afford to give that kind of "empowerment" to most developers, especially if these companies rely heavily on masses of junior/inexperienced developers. So they figure a strong management layer is necessary to properly direct the project's goals. Now I'm not saying that's how it should be, but that's the reality of the software talent market today.
- tikhonj 6y ago
  I've heard this before but it strikes me as a fundamentally condescending view. I've found that most people, including junior developers, more than rise to the occasion as long as they're given trust, a real understanding of where the team is moving collectively and an environment where asking for help (or even direction!) feels comfortable and natural. The problem is that this means you need leaders—managers or not—who are comfortable without an illusion of control or visibility and who understand how to lead and communicate effectively. And you really need this all the way up the chain. If you manage this, though, you'll be amazed at how productive even heavily junior teams can be.
  - jasondigitized 6y ago
    The illusion of control via rituals, status meetings, spreadsheets,JIRA, etc is a plague throughout the industry. Cargo cult and “making someone happy”. We do far too many thing simply because if you say you do it, your CTO / VP will be happy.
- danabrams 6y ago
  > these companies rely heavily on masses of junior/inexperienced developers. So they figure a strong management layer is necessary to properly direct the project's goals. Development isn’t an assembly line process—and cannot possibly be. It’s about theory building and mental models. It requires experience. It’s fine to have juniors, but they need to lean heavily on experienced colleagues. No amount of management and no management process can change that. A team where the juniors outnumber the seniors 3-to-1 is going to cost more money in the long run. What you’re describing is exactly what I’m talking about when I say companies are unable to achieve this. Hire 3 senior people instead of 12 junior. You’ll get more done. Reduce your collaboration costs. But, as a manager, you get paid more if you manage more people, or if the people below you manage more people, so there’s a perverse incentive to build as much bureaucracy as possible and staff the lowest layers with the cheapest possible hires.
a_imho 6y ago
Individuals and interactions over processes and tools Anyone who says the Agile Manifesto and Scrum are not directly at odds is trying to sell you something.
mempko 6y ago
Exactly. Notice scrum has no managers. There is no manager role in scrum. Yet companies still have managers? why? Makes no sense if you are really doing scrum right. How many companies actually implemented scrum and got rid of their managers?

Viliam1234 6y ago

> Agile is about ditching managers, bureaucracy, and estimates in favor of empowering the team itself. Scrum (as intended, not as actually done in most companies) is in essence a set of rules to prevent things from falling apart after you have ditched the managers: * know what you want to achieve during this month -- planning for longer time is unrealistic, weekly planning is micromanagement; * at the end of the month, make a demo of new features -- make sure that all pieces fit together, and get feedback whether this is actually what the customer wanted; * reflect on what happened during this month and why -- this is the moment to speak freely, complain, and propose changes (for example, this is the occassion when the developers could collectively decide to stop using Jira); * decide where to go during the next month -- together with the customer: the customer decides "what first", developers decide "how fast"; * make sure your colleagues know what you do and whether you need help -- this shouldn't take more than 3 minutes a day. If your sprints are weekly, you are doing it wrong. If you don't make a demo, you are doing it wrong. First, with continuous integration, deploying the demo should be trivial. Second, if you don't show the demo to the customer, who is giving you feedback on your progress? (Nobody? Management?) If you skip the retrospective, or if you don't feel free to speak openly during the retrospective, you are doing it wrong. If you don't have an idea what to do next, and what is important for the customer, you are doing it wrong. If management gives you deadline, you are doing it wrong. If your daily standup takes more than three minutes, you are doing it wrong. (For anything that requires more time, you should arrange a separate meeting, for only the people involved, not the whole team. Note that the "separate meeting" could still be like five or ten minutes long.) So much for the dream. Now here is what actually happens: in your company, the managers have the power, and they are not going to fire themselves. So instead, they will impose on you some kind of management-driven pseudo-Scrum, which looks like this: The sprints are short, because that gives the managers greater feeling of control. You don't talk to the the actual customer, and the customer doesn't see your product before it is officially delivered; the managers acting as middlemen is how they justify their jobs. There is no retrospective, because this is the first and the last time in history when management decides that something is a waste of time. You have sprint planning, but you also have deadlines, so your choices are often limited to "do X this sprint and Y next sprint, or do Y this sprint and X next sprint". The daily, instead of team members synchronizing with each other, becomes team members reporting to the manager. You get Jira, which is set up according to the manager's wishes. This is not a coincidence. The managers insist it needs to be done this way, because they want to protect their jobs. The same thing would happen with any other methodology.

vesinisa 6y ago
> for example, this is the occassion when the developers could collectively decide to stop using Jira That's the gold standard! You know you are doing fake agile when the team is not allowed to decide stop using Jira. In all seriousness, thanks - very valued insights! I did not even know those were the original purposes of the Scrum ceremonies, having only ever worked witn almost exactly the kind of pseudo-Scrum you describe.
- Too 6y ago
  Perfect litmus test indeed! I worked in one place where scrum master - the person explicitly assigned to protect the team - was the one who most loudly imposed that the company configured Jira shall be used. Despite this being brought up as a PITA every retrospective. This is the moment you know you are doing fake Agile and your scrummaster is just the managers puppet in disguise to spy on the team.
  - Viliam1234 6y ago
    It is difficult for the Scrum Master to be impartial in a situation where the management ultimately decides who will be the Scrum Master and whether Scrum will be used at all. I am not sure what would be the right solution. One possibility is to fire the management, or never even hire them at first place -- if you want to have a software company that uses Scrum, do it from start. Another possibility is to have a Scrum Master with strong political skils... which more or less means, it cannot be a former developer. Probably the fatal mistake is having too many managers in the company. At that moment, it is practically guaranteed that they will try to interfere with everything. They have to, because that is how they protect their own jobs. And they will hire more managers, because that is one way to get higher on the company ladder (hire more people into positions below you). And at that moment, everything is doomed, because now the company serves the managers instead of the other way round. I guess this means that Scrum can work as intended only in small companies. Where the Scrum Master is not below several layers of management, but on the same level as the few managers, right below the company owner.
blabitty 6y ago

vesinisa 6y ago

Couldn't agree more. Just quit my job of last six years the previous week. I really liked the team and the product. We had a very informal development process - we all agreed it was agile but not through following any formal process (Scrum or such). We still had retros and dailies. Planning was done by managers explaining a feature they'd like us to do, and the team then doing the planning, design and implementation. More processes and e.g. recurring meetings were erected and torn down based on the team's actual needs alone. If someone wanted an estimate, we'd give it, but we were not doing continuos estimation just for the sake of estimation itself, like in Scrum. Felt like the process served us, rather than us serving a process. If you'd taken a look at the Agile manifesto, we were ticking pretty much all the boxes: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html Then 1.5 years ago, company decided to roll out whole IT department wide SAFe, which is basically Scrum but on a whole organization level, and hence even more bureaucratic and with one additional level of mega-iterations added on top of Scrum's sprints. Suddenly, our team is assigned a Scrum master and we no longer even get to speak directly with the managers who previously negotiated new features with us. Instead, everything has to go through multiple levels of prioritization and broken telephones of new SAFe intermediaries. We started attending 2-3 new mandatory processes / recurring meetings, meaning time spent in inefficient boring meetings went up significantly. We had to also start a much more stringent ticketing system regime, including having to estimate ALL work. Despite multiple requests from Scrum master and managers, nobody was ever able to explain why estimating absolutely everything - even when nobody had even asked for an estimate - helped with anything. It was seemingly taken as a religious thesis that it was just the right thing to do. Soon, the team was paralyzed. Even simple features became harder and harder to develop. Despite the massive effort spent on estimating even the most trivial of tasks, the big picture was forgotten about because larger feature-level ballpark estimates were no longer acceptable, and hence unimportant. On a company level, the business managers that previously talked directly to us just basically quit working with the IT department because the SAFe process was such a beast to contend. It was easiest for them to just stop asking for new digital product features, and focus on non-IT projects instead. I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way - Scrum consultants love to gloat when some metric improves, but if things go south the org has only itself to blame for failing to correctly convert to their favorite flavor of True Agile System™. My experience was however seeing an Agile team (as expressed by the Agile manifesto) turn into a Monty Python parody of agile software development just by being forced to submit to these "fake agile" heavy processes and hierarchies.

masterphilo 6y ago

> But most companies are incapable of the kind of equality and empowerment necessary to achieve agility, so they will force the terrible cargo cult version upon us. I would argue that most companies cannot afford to give that kind of "empowerment" to most developers, especially if these companies rely heavily on masses of junior/inexperienced developers. So they figure a strong management layer is necessary to properly direct the project's goals. Now I'm not saying that's how it should be, but that's the reality of the software talent market today.

tikhonj 6y ago
I've heard this before but it strikes me as a fundamentally condescending view. I've found that most people, including junior developers, more than rise to the occasion as long as they're given trust, a real understanding of where the team is moving collectively and an environment where asking for help (or even direction!) feels comfortable and natural. The problem is that this means you need leaders—managers or not—who are comfortable without an illusion of control or visibility and who understand how to lead and communicate effectively. And you really need this all the way up the chain. If you manage this, though, you'll be amazed at how productive even heavily junior teams can be.
- jasondigitized 6y ago
  The illusion of control via rituals, status meetings, spreadsheets,JIRA, etc is a plague throughout the industry. Cargo cult and “making someone happy”. We do far too many thing simply because if you say you do it, your CTO / VP will be happy.
danabrams 6y ago
> these companies rely heavily on masses of junior/inexperienced developers. So they figure a strong management layer is necessary to properly direct the project's goals. Development isn’t an assembly line process—and cannot possibly be. It’s about theory building and mental models. It requires experience. It’s fine to have juniors, but they need to lean heavily on experienced colleagues. No amount of management and no management process can change that. A team where the juniors outnumber the seniors 3-to-1 is going to cost more money in the long run. What you’re describing is exactly what I’m talking about when I say companies are unable to achieve this. Hire 3 senior people instead of 12 junior. You’ll get more done. Reduce your collaboration costs. But, as a manager, you get paid more if you manage more people, or if the people below you manage more people, so there’s a perverse incentive to build as much bureaucracy as possible and staff the lowest layers with the cheapest possible hires.

a_imho 6y ago

Individuals and interactions over processes and tools Anyone who says the Agile Manifesto and Scrum are not directly at odds is trying to sell you something.

mempko 6y ago

Exactly. Notice scrum has no managers. There is no manager role in scrum. Yet companies still have managers? why? Makes no sense if you are really doing scrum right. How many companies actually implemented scrum and got rid of their managers?