5 ms·

Agile is a generic umbrella term that involves a vast array of complex, subtle knowledge and skills. It's like saying "Engineer", or "Chef". Each has a shared s

Agile is a generic umbrella term that involves a vast array of complex, subtle knowledge and skills. It's like saying "Engineer", or "Chef". Each has a shared skillset, to be sure. But each category's members can't just work the same way at all jobs, and there's no book on how to be an Engineer or Chef everywhere. The Agile Manifesto is a failure at trying to make Agile happen because it can't tell you how to make it happen, because it varies wildly. No manager can read a book on how to "Agile-ify" their org, they have to apply their brains and figure out how their specific version of "Agile" will work. But the skill-set required to do this is not a Managerial skill, it is a lower-level-worker skill. But it's also a very advanced lower-level-worker skill. And that's why things like "Agile", "DevOps", etc will fail. People at the higher end have no clue how to make it happen, and people at the lower end who have an idea how to make it happen don't have the power to make the organizational changes to do so. You need a way for the lower-end people to tell the higher-end people what to do, and have the higher-end people listen to them, and make the changes happen. This is very hard in a traditional organizational hierarchy, because higher-end people have big egos and bigger concerns over things like politics.

xamde 5y ago
Nice explanation. Amusingly, it explains why NO kind of informed change can happen in a hierarchical organisation.
- pjmlp 5y ago
  The old Microsoft (the new one is much better at this), you couldn't just go around sharing department knowledge, if you on lets say Visual Basic team wanted the deep knowledge for a Windows feature as means to product improvement, it was easier to have a neutral contractor somehow get hold of the information across departments, than asking directly as Microsoft employee.
emptysongglass 5y ago
> And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about. If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement it in this way over this other way do you really think I'm going to listen to them if it's clear they have no idea what the implementation details are let alone the tools? Of course not. I'm making DevOps happen and I do that by knowing the tools and practices. I'm being given the power I need to make it happen. I earn the respect every day I come in and write the code or identify the weaknesses we need to shore up to move faster.
- zorpner 5y ago
  > I earn the respect every day I come in How much of each dollar you make for the company with your hard work do you take home?
  - bosie 5y ago
    Any advice on how to calculate the first?
    - pjmlp 5y ago
      For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. As for how much money it costs me an FTE to play around something outside the planned roadmap, their monthly salary divided by the amount of hours they are supposed to be working per month, correlated with the time spent on said activity. Actually I have been in a couple of projects, where instead of sprint points or hours, we actually had euros as ticket efforts.
      - bosie 5y ago
        > For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. No, that is just accounting of salaries. That doesn't calculate the value/worth of the work and hence can't be used to determine salaries. That's circular logic. > For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. That is not really what I was asking for or my parent talking about. We were talking about specific salaries. Engineer X wants Y salary. justified or not? You are suggesting revenue/hours. With that logic, everyone gets the same salary and you would also value the identical work differently depending on the revenue (which might or might not be justified)
brundolf 5y ago
The product and engineering managers I've had in the past have generally been humble, acting as a touchstone of coordination for the folks on the ground rather than a controlling force. And the engineering managers have all just been former engineers who decided they preferred doing this kind of facilitation work instead of writing code. Maybe this isn't the norm?
- jordanbeiber 5y ago
  Most places buying these process frameworks are enterprise shops where that absolutely is NOT the norm. Wich makes it all a glorious Catch 22. These companies, that rely completely on software, are unable to make the required leadership changes. It’s cultural.
- pjmlp 5y ago
  I do enterprise consulting for a couple of years, the kind of organisations that buy Oracle or MSDN licenses without thinking twice about it. The best I have seen were mini-silos that managed to de-couple themselves from the org chart. However I also have seen that it hardly lasts more than a couple of years, because as soon as someone noticed the success of the business unit they were re-integrated so that they could teach the reasons for their success to others. You can imagine how well did they usually fare afterwards.
- g051051 5y ago
  In my experience, it most definitely is not.

xamde 5y ago

Nice explanation. Amusingly, it explains why NO kind of informed change can happen in a hierarchical organisation.

pjmlp 5y ago
The old Microsoft (the new one is much better at this), you couldn't just go around sharing department knowledge, if you on lets say Visual Basic team wanted the deep knowledge for a Windows feature as means to product improvement, it was easier to have a neutral contractor somehow get hold of the information across departments, than asking directly as Microsoft employee.

emptysongglass 5y ago

> And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about. If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement it in this way over this other way do you really think I'm going to listen to them if it's clear they have no idea what the implementation details are let alone the tools? Of course not. I'm making DevOps happen and I do that by knowing the tools and practices. I'm being given the power I need to make it happen. I earn the respect every day I come in and write the code or identify the weaknesses we need to shore up to move faster.

zorpner 5y ago
> I earn the respect every day I come in How much of each dollar you make for the company with your hard work do you take home?
- bosie 5y ago
  Any advice on how to calculate the first?
  - pjmlp 5y ago
    For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. As for how much money it costs me an FTE to play around something outside the planned roadmap, their monthly salary divided by the amount of hours they are supposed to be working per month, correlated with the time spent on said activity. Actually I have been in a couple of projects, where instead of sprint points or hours, we actually had euros as ticket efforts.
    - bosie 5y ago
      > For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. No, that is just accounting of salaries. That doesn't calculate the value/worth of the work and hence can't be used to determine salaries. That's circular logic. > For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. That is not really what I was asking for or my parent talking about. We were talking about specific salaries. Engineer X wants Y salary. justified or not? You are suggesting revenue/hours. With that logic, everyone gets the same salary and you would also value the identical work differently depending on the revenue (which might or might not be justified)

brundolf 5y ago

The product and engineering managers I've had in the past have generally been humble, acting as a touchstone of coordination for the folks on the ground rather than a controlling force. And the engineering managers have all just been former engineers who decided they preferred doing this kind of facilitation work instead of writing code. Maybe this isn't the norm?

jordanbeiber 5y ago
Most places buying these process frameworks are enterprise shops where that absolutely is NOT the norm. Wich makes it all a glorious Catch 22. These companies, that rely completely on software, are unable to make the required leadership changes. It’s cultural.
pjmlp 5y ago
I do enterprise consulting for a couple of years, the kind of organisations that buy Oracle or MSDN licenses without thinking twice about it. The best I have seen were mini-silos that managed to de-couple themselves from the org chart. However I also have seen that it hardly lasts more than a couple of years, because as soon as someone noticed the success of the business unit they were re-integrated so that they could teach the reasons for their success to others. You can imagine how well did they usually fare afterwards.
g051051 5y ago
In my experience, it most definitely is not.