11 ms·

A looong time ago I went through Army basic training. As a BS degree holder I was given the job of "book man". This meant I carried around the platoon training

A looong time ago I went through Army basic training. As a BS degree holder I was given the job of "book man". This meant I carried around the platoon training book and carried placards to put in signs at various training locations that told what battalion, company, and platoon we were so if anyone driving by a gun range, motor pool, or classroom could look and see oh that's 1st platoon, C company, 1st training battalion. I've come to believe that that main driver for Agile adoption has come to be something similar. Making visible to outsiders what software development teams are doing, and making progress (or it's lack) visible to management. I thinks that's a completely reasonable expectation. Businesses are paying exorbitant salaries and providing ping pong tables, why shouldn't they have visibility into what's being done? Where it becomes toxic is in areas this posts parent indicates; posturing, one upsmanship, pressure to perform. Effective teams need "safe spaces" to learn, discover, try and fail. Agile isn't that anymore. Hasn't been for a long time.

plughs 6y ago
There are certainly good reasons to make a team's progress visible. PMs/POs ( I'm never sure of the difference ) will want to know if a project can meet the release date. They will want to know that the need-to-have features are being worked on before the nice-to-have. I don't want to sat a team should work in total isolation. I can only say that IME a team is going to be a lot more productive if they are able to own their development process. Good infrastructure, knowledgeable engineers, healthy relationships instead of competitive ones - that's what creates a highly productive team and highly productive engineers.
- lonelappde 6y ago
  > will want to know if a project can meet the release date The number one main headline takeway axiom of Agile is that this question is completely banned. Agile is about delivering working software continuously, delivering whatever increment you get working at each timepoint, adapting to observed reality as it comes, and not having deadlines for specific features that might turn out to be impossible or harder than estimated.
  - satyrnein 6y ago
    That question is not banned; story points and velocity measurements are mainstream agile, right?
    - davidwf 6y ago
      "Banned" may not be the right word, but I do agree it's the wrong question. Story points and velocity measurements are about giving a reasonable guess about what's "likely" to be completed at any given point in time in the future, with bigger error bars the further out you look. Agile projects don't "complete" so much as a decision is made to release at a given point, and everyone is happier with agile in an environment where there's an expectation of multiple, continuous releases.
    - loopz 6y ago
      Except they are used wrong and not required for agility. How many tasks per time is an observation, a hypothesis about usefulness of projection. Story points? Waste.
  - axlee 6y ago
    That question is banned until a board meeting comes up and your owners asks you "What are your plans for the products the next quarter, misters CEO and CTO"? If you babble around saying plans and deadlines are for suckers and that things will happen when they will happen, I am not sure they will keep paying you and your team's salaries for long. This new contrarian cargo cult of waving away any kind of medium-term planning or estimation is hurting businesses as much, if not more, as when all projects were waterfalled and timeboxed to death. Yes, estimating is hard to get right. No, it does not mean we should simply get rid of it. Because engineers do not live in a little bubble of code: there is usually a whole company around them who need insight into what is getting built and when they can expect it. And anybody who believes that asking this question is too much or intrusive has never worked in a non-engineering position, or think of themself too much.
    - BigJono 6y ago
      The mistake here is making your measurements too granular. What happens is the board meets, long and medium term plans are made, etc etc. That's all good. Then what happens is every level of management calls in the banners and forces them to pitch how they align their teams and projects to whatever was pitched one level up. Somewhere along the process, you hit the point where planning stops being a positive and starts being a liability. This process never stops, until you have some toothless PM slave driving devs because they're 8 levels removed from the strategic planning and they've pitched a 40-point/week development rate to their boss because they don't have enough information to do anything else. Anybody that tries to break the pattern is going to find themselves on the receiving end of an unfavourable performance review in any big business I've ever worked for. There's a happy middle ground somewhere, where devs are given plenty of space to work but their output is still tied to the business's long term objectives. How you reliably reach that middle ground is probably a 8/9/10 figure question depending on the business.
MattGaiser 6y ago
> making progress (or it's lack) visible to management. The challenge is that management is only looking through a small window and everything from promotions to raises to favours are dished out based on that window. Anything not in view of that window immediately obviously becomes useless to one's advancement in a company, so the window better cover everything which matters and it usually doesn't.
- kubanczyk 6y ago
  "Advancement" seems a big deal.
droopyEyelids 6y ago
Not related to your main point, but would you reconsider calling them 'exorbitant salaries'? Engineering is one of the only professions that is paid commensurate to the value they provide Calling our salaries 'exorbitant' leaves you without superlatives left to describe executives that get paid thousands of times our wage, and at least they do work compared to the owners of capital who are 'paid' incredible money without doing any work at all. To call an engineer salary 'exorbitant' you must be comparing it to the salary of people who function as modern serfs, and are not paid commensurate with the value they provide, or even enough to live a safe and satisfied life. Being paid enough for modest freedom and security is not 'exorbitant' though- no matter what you're comparing it to.
- Avicebron 6y ago
  Outside of software the majority of American's function as modern serfs. I'm an engineer who doesn't work in software and live as a modern serf
dsfdsfsdfasd 6y ago
That's a really interesting idea that I never thought about. Seems to make a lot of sense. As far as business deserves to know what they are paying for, that is absolutely correct as well. The problem is that business is not paying for story points. They are paying for actual product and delivery. So when they measure output by story points, you end up with a situation where teams are trying to maximize story points delivery, etc. as opposed to actual product delivery.
- LoSboccacc 6y ago
  > business is not paying for story points. They are paying for actual product and delivery. but that's the whole problem, if you constrain time, cost and result there's no any space left for agility. the point of agile is to maximize the value of what can be produced with a given team within a given project, you picked time and cost and you apply agile to emerge stories that are actually important to you and push back on the gold plating. if you have all three fixed, waterfall works just fine, actually even better.
narag 6y ago
Making visible to outsiders what software development teams are doing, and making progress (or it's lack) visible to management. I thinks that's a completely reasonable expectation. The devil is in the details and in this case literally because the granularity of progress is too fine-grained to be exposed away from its context. The project manager or whatever you call the nearest person with power over your time needs some leeway to organize, ask for some extra, compensate, forgive, and reward you, without higher powers micromanaging. Freedom is the premise of responsability. Absolute evil happens when customer demands access to hourly activity log for each developer in the (not on premises) project.
- kubanczyk 6y ago
  > Freedom is the premise of responsability. Is it? Maybe it's the opposite? Citation needed.
sanderjd 6y ago
It is reasonable but it is not necessarily the smartest way of going about things. The question of whom things are visible to is an important one. Your comment says "management", and yeah that's one common way of thinking about it. But managers are just individuals with their own motivations. It is really "the business" that wants visibility in order to best accomplish its goals. There is an assumption that "management" is better aligned with "the business" than the employees they are paying "exorbitant" salaries to. But that may or may not be true, managers are also just individuals with their own motivations. So to the extent that it is true that managers are better aligned with the business, why is that the case? I see a few things that trend in that direction: compensation that is more tied to the performance of the business (through bonuses or what have you), more visibility into the goals and reasoning for decisions being made by leadership, and a better grounding in the dynamics of the business (what is the strategy, how does its market work, how does it make money). The theory is that because of those things (and probably others I'm not thinking of), the managers are better suited to be representing the interests of the business, whereas the engineers are just tools those managers can use to further those interests. That is one way of doing it, probably the most common way, and it definitely seems like management visibility into work is extremely important in such a setup. But another way might be to align the engineers with the business in the same way managers are: pay bonuses based on the performance of the business, give them visibility into goals and decisions, teach them about the strategy of the business and the dynamics of how it makes money. That is, give the engineers ownership in the same way management has ownership, and trust them to make decisions that are in the interest of the business. To put this another way: if you trust managers to make decisions about trade-offs that are in the best interest of the business, why can't you trust engineers as well? Are the engineers dumber or shiftier than the managers such that they can't be trusted with this?
- musicale 6y ago
  > give the engineers ownership in the same way management has ownership, and trust them to make decisions that are in the interest of the business. that's crazy talk ;-)
- Tyrek 6y ago
  The general line of argument here is that the managers have spent time and effort as part of their professional development in order to understand the business, whereas the engineers have dedicated their time towards a more technical focus. This is reflected in how they spend their days - the manager spends time in meetings, whereas the engineer is spending time coding (very broad generalization) Assuming that neither side is doing significant amounts of extracurricular work to bridge the gap, it therefore follows that management understands the business better, because that is explicitly the purpose of their job. In a best case scenario, it makes sense to provide engineers etc. with the context to understand the decisions. On the flip side, business decisions are often made upon a huge heap of context that is generally invisible to the engineer (unless they spend an equal amount of time in building up their business knowledge, spending time in meetings, etc. - but at that point, they're basically a manager?) It's not to say that engineers can't develop the background, etc. to make the decisions, but that it's not exactly part of the expected job functions, and not something that's explicitly looked for as part of the recruitment process. In a sense, this is a bit of a tautological issue.
choeger 6y ago
> I thinks that's a completely reasonable expectation. Most often it is not. The problem is that management does not understand shit about software. And they usually don't care to learn about it. Hence this is about as effective as me asking for transparency regarding a COVID-19 vaccine. Yes, the practitioners could tell me they are in a phase-II trial. But to process that information fully and put it into context, I'd effectively need to study medicine.
jjjensen90 6y ago
Software engineering salaries are not exorbitant. In fact, engineers may be consistently underpaid for the value delivered. A small team can create millions for executives and shareholders. Ping pong tables etc are a sad tool for management to placate the people who drive the company value up, to keep them from unionizing and realizing the power they hold.
- Jasper_ 6y ago
  > Software engineering salaries are not exorbitant. In fact, engineers may be consistently underpaid for the value delivered. What about the value of those who cooked your lunch? Without them, software engineers would starve and die, so that makes them have far more value, no? Do you think that food service workers are also underpaid?
  - loopz 6y ago
    whataboutism
    - Jasper_ 6y ago
      When asking about the value that a certain occupation provides, I think it's fair to compare them to the rest of society and ask about the balance. I'm not bringing up the plight of other employees randomly to dismiss one argument, I'm asking for a defense of the stark difference in economic status.
      - perl4ever 6y ago
        Right now a lot more meals than usual are being prepared at home, and a lot of people who had jobs doing that are out of work. On the other hand, essentially the entire accounting system for the state hardest hit by coronavirus is run by "nonessential" employees, because that is what we are calling people who can work from home. Right now, there are definitely lots of people who can't work from home that are enormously essential in the ordinary sense. For instance, say you have a plumbing emergency. But, you know, your unemployment check is pretty essential too.
smadge 6y ago
> Businesses are paying exorbitant salaries and providing ping pong tables Businesses are paying market rate salaries to employees who generate them revenue. If anything engineers should be the ones questioning the exorbitant compensation and perks at the top of the org structure. > why shouldn't they have visibility into what's being done? Because they shouldn't be micromanaging. They should be setting high level goals and expectations and giving teams autonomy and trust. Intrusive surveillance and low level metrics create perverse incentives that detract from those high level goals.
- rrrrrrrrrrrryan 6y ago
  But how can they set goals without any visibility into what a team can typically accomplish in a given time period? How can they identify better performers and worse performers? I'm not saying agile is the right solution, (it probably isn't), but expecting higher-ups to fund a black-box team is kind of naive.
  - kyuudou 6y ago
    Ye olde SV Scrum clip[1] "This just became a JOB..." -Gilfoyle [1]https://www.youtube.com/watch?v=oyVksFviJVE https://www.youtube.com/watch?v=oyVksFviJVE S01E05 Scrum scene I do like Agile, it's the typical problem of managers misusing it to micromanage, engage in useless metrics etc.
  - jiggawatts 6y ago
    Measure the deliverable, not the deliverers. Reporting on random internal stuff instead of the actual problem at hand is the #1 problem I see with corporate reporting, everywhere. I see various combinations of people wasting time measuring: 1) The thing that is easy to measure, typically money or time. 2) The things they "understand", typically people for HR, compliance for legal, money for finance, etc... 3) The things their manager wants to know, no matter how irrelevant that is to executing their own job well. Meanwhile what they should be measuring is the qualities of the end-product or the overall external customer end result. It doesn't matter one iota if Bob the Developer Guy missed an internal 3-day deadline that John the Manager made up on the spot if the end product is a winner in the market and makes the users ecstatically happy to part with their money. This happens everywhere, with everybody. For an IT-centric example, the common one I see is: Helpdesk: "The users are complaining that the app is slow" Admins: "The load is only 10%, but fine, we'll add more capacity!" Helpdesk: "The app is still slow!" Admins: "The load is only 5%! They should have no reason to complain!" Do you see the issue? No, seriously: do you? Because practically nobody does, in my experience. Take a minute. What happened here is that the admins measured the thing that is easy for them to measure: the load. There's a cute little bar graph in VMware, or a chart in their network appliance, or whatever. What they should have been measuring is latency from the end-user perspective, but that's hard to measure and practically no product tells you this number out of the box. So their entire process, their reporting, their troubleshooting, their forms, requests, everything becomes focused on the thing that they can see and control. Even if it's pointless, ineffective, and basically a waste of everyone's time and effort. This happens with developers in exactly the same manner. Software quality is stupid hard to measure. Long term supportability is borderline impossible to measure without a time machine. Technical debt is hard to even explain to a manager, let alone keep tabs on in terms of numbers. So what's easy to measure? Time! Deadlines, sprints, release dates, etc... That's super easy. That's why inevitably the unimportant internal time metrics become critical to everybody, but the actually important metrics aren't even measured and become invisible to management until it's far too late.
jay_kyburz 6y ago
If outsiders want to see whats going on in an Agile team, all they need to do is run the "working software". They don't need to see all the ugly bits under the covers. Having working software is line two of the Manifesto. They can run it each week and see whats new. Even better, they can provide feedback on the working software and the team can then quickly respond to that feedback. In a week or two, when the outsider next looks at the working software they will see the software improved.
- artsyca 6y ago
  The quality of the software is the best metric of whether the process is working but management has no incentive to blame the process when it breaks down and every incentive to blame the people instead

plughs 6y ago

There are certainly good reasons to make a team's progress visible. PMs/POs ( I'm never sure of the difference ) will want to know if a project can meet the release date. They will want to know that the need-to-have features are being worked on before the nice-to-have. I don't want to sat a team should work in total isolation. I can only say that IME a team is going to be a lot more productive if they are able to own their development process. Good infrastructure, knowledgeable engineers, healthy relationships instead of competitive ones - that's what creates a highly productive team and highly productive engineers.

lonelappde 6y ago
> will want to know if a project can meet the release date The number one main headline takeway axiom of Agile is that this question is completely banned. Agile is about delivering working software continuously, delivering whatever increment you get working at each timepoint, adapting to observed reality as it comes, and not having deadlines for specific features that might turn out to be impossible or harder than estimated.
- satyrnein 6y ago
  That question is not banned; story points and velocity measurements are mainstream agile, right?
  - davidwf 6y ago
    "Banned" may not be the right word, but I do agree it's the wrong question. Story points and velocity measurements are about giving a reasonable guess about what's "likely" to be completed at any given point in time in the future, with bigger error bars the further out you look. Agile projects don't "complete" so much as a decision is made to release at a given point, and everyone is happier with agile in an environment where there's an expectation of multiple, continuous releases.
  - loopz 6y ago
    Except they are used wrong and not required for agility. How many tasks per time is an observation, a hypothesis about usefulness of projection. Story points? Waste.
- axlee 6y ago
  That question is banned until a board meeting comes up and your owners asks you "What are your plans for the products the next quarter, misters CEO and CTO"? If you babble around saying plans and deadlines are for suckers and that things will happen when they will happen, I am not sure they will keep paying you and your team's salaries for long. This new contrarian cargo cult of waving away any kind of medium-term planning or estimation is hurting businesses as much, if not more, as when all projects were waterfalled and timeboxed to death. Yes, estimating is hard to get right. No, it does not mean we should simply get rid of it. Because engineers do not live in a little bubble of code: there is usually a whole company around them who need insight into what is getting built and when they can expect it. And anybody who believes that asking this question is too much or intrusive has never worked in a non-engineering position, or think of themself too much.
  - BigJono 6y ago
    The mistake here is making your measurements too granular. What happens is the board meets, long and medium term plans are made, etc etc. That's all good. Then what happens is every level of management calls in the banners and forces them to pitch how they align their teams and projects to whatever was pitched one level up. Somewhere along the process, you hit the point where planning stops being a positive and starts being a liability. This process never stops, until you have some toothless PM slave driving devs because they're 8 levels removed from the strategic planning and they've pitched a 40-point/week development rate to their boss because they don't have enough information to do anything else. Anybody that tries to break the pattern is going to find themselves on the receiving end of an unfavourable performance review in any big business I've ever worked for. There's a happy middle ground somewhere, where devs are given plenty of space to work but their output is still tied to the business's long term objectives. How you reliably reach that middle ground is probably a 8/9/10 figure question depending on the business.

MattGaiser 6y ago

> making progress (or it's lack) visible to management. The challenge is that management is only looking through a small window and everything from promotions to raises to favours are dished out based on that window. Anything not in view of that window immediately obviously becomes useless to one's advancement in a company, so the window better cover everything which matters and it usually doesn't.

kubanczyk 6y ago
"Advancement" seems a big deal.

droopyEyelids 6y ago

Not related to your main point, but would you reconsider calling them 'exorbitant salaries'? Engineering is one of the only professions that is paid commensurate to the value they provide Calling our salaries 'exorbitant' leaves you without superlatives left to describe executives that get paid thousands of times our wage, and at least they do work compared to the owners of capital who are 'paid' incredible money without doing any work at all. To call an engineer salary 'exorbitant' you must be comparing it to the salary of people who function as modern serfs, and are not paid commensurate with the value they provide, or even enough to live a safe and satisfied life. Being paid enough for modest freedom and security is not 'exorbitant' though- no matter what you're comparing it to.

Avicebron 6y ago
Outside of software the majority of American's function as modern serfs. I'm an engineer who doesn't work in software and live as a modern serf

dsfdsfsdfasd 6y ago

That's a really interesting idea that I never thought about. Seems to make a lot of sense. As far as business deserves to know what they are paying for, that is absolutely correct as well. The problem is that business is not paying for story points. They are paying for actual product and delivery. So when they measure output by story points, you end up with a situation where teams are trying to maximize story points delivery, etc. as opposed to actual product delivery.

LoSboccacc 6y ago
> business is not paying for story points. They are paying for actual product and delivery. but that's the whole problem, if you constrain time, cost and result there's no any space left for agility. the point of agile is to maximize the value of what can be produced with a given team within a given project, you picked time and cost and you apply agile to emerge stories that are actually important to you and push back on the gold plating. if you have all three fixed, waterfall works just fine, actually even better.

narag 6y ago

Making visible to outsiders what software development teams are doing, and making progress (or it's lack) visible to management. I thinks that's a completely reasonable expectation. The devil is in the details and in this case literally because the granularity of progress is too fine-grained to be exposed away from its context. The project manager or whatever you call the nearest person with power over your time needs some leeway to organize, ask for some extra, compensate, forgive, and reward you, without higher powers micromanaging. Freedom is the premise of responsability. Absolute evil happens when customer demands access to hourly activity log for each developer in the (not on premises) project.

kubanczyk 6y ago
> Freedom is the premise of responsability. Is it? Maybe it's the opposite? Citation needed.

sanderjd 6y ago

It is reasonable but it is not necessarily the smartest way of going about things. The question of whom things are visible to is an important one. Your comment says "management", and yeah that's one common way of thinking about it. But managers are just individuals with their own motivations. It is really "the business" that wants visibility in order to best accomplish its goals. There is an assumption that "management" is better aligned with "the business" than the employees they are paying "exorbitant" salaries to. But that may or may not be true, managers are also just individuals with their own motivations. So to the extent that it is true that managers are better aligned with the business, why is that the case? I see a few things that trend in that direction: compensation that is more tied to the performance of the business (through bonuses or what have you), more visibility into the goals and reasoning for decisions being made by leadership, and a better grounding in the dynamics of the business (what is the strategy, how does its market work, how does it make money). The theory is that because of those things (and probably others I'm not thinking of), the managers are better suited to be representing the interests of the business, whereas the engineers are just tools those managers can use to further those interests. That is one way of doing it, probably the most common way, and it definitely seems like management visibility into work is extremely important in such a setup. But another way might be to align the engineers with the business in the same way managers are: pay bonuses based on the performance of the business, give them visibility into goals and decisions, teach them about the strategy of the business and the dynamics of how it makes money. That is, give the engineers ownership in the same way management has ownership, and trust them to make decisions that are in the interest of the business. To put this another way: if you trust managers to make decisions about trade-offs that are in the best interest of the business, why can't you trust engineers as well? Are the engineers dumber or shiftier than the managers such that they can't be trusted with this?

musicale 6y ago
> give the engineers ownership in the same way management has ownership, and trust them to make decisions that are in the interest of the business. that's crazy talk ;-)
Tyrek 6y ago
The general line of argument here is that the managers have spent time and effort as part of their professional development in order to understand the business, whereas the engineers have dedicated their time towards a more technical focus. This is reflected in how they spend their days - the manager spends time in meetings, whereas the engineer is spending time coding (very broad generalization) Assuming that neither side is doing significant amounts of extracurricular work to bridge the gap, it therefore follows that management understands the business better, because that is explicitly the purpose of their job. In a best case scenario, it makes sense to provide engineers etc. with the context to understand the decisions. On the flip side, business decisions are often made upon a huge heap of context that is generally invisible to the engineer (unless they spend an equal amount of time in building up their business knowledge, spending time in meetings, etc. - but at that point, they're basically a manager?) It's not to say that engineers can't develop the background, etc. to make the decisions, but that it's not exactly part of the expected job functions, and not something that's explicitly looked for as part of the recruitment process. In a sense, this is a bit of a tautological issue.

choeger 6y ago

> I thinks that's a completely reasonable expectation. Most often it is not. The problem is that management does not understand shit about software. And they usually don't care to learn about it. Hence this is about as effective as me asking for transparency regarding a COVID-19 vaccine. Yes, the practitioners could tell me they are in a phase-II trial. But to process that information fully and put it into context, I'd effectively need to study medicine.

jjjensen90 6y ago

Software engineering salaries are not exorbitant. In fact, engineers may be consistently underpaid for the value delivered. A small team can create millions for executives and shareholders. Ping pong tables etc are a sad tool for management to placate the people who drive the company value up, to keep them from unionizing and realizing the power they hold.

Jasper_ 6y ago
> Software engineering salaries are not exorbitant. In fact, engineers may be consistently underpaid for the value delivered. What about the value of those who cooked your lunch? Without them, software engineers would starve and die, so that makes them have far more value, no? Do you think that food service workers are also underpaid?
- loopz 6y ago
  whataboutism
  - Jasper_ 6y ago
    When asking about the value that a certain occupation provides, I think it's fair to compare them to the rest of society and ask about the balance. I'm not bringing up the plight of other employees randomly to dismiss one argument, I'm asking for a defense of the stark difference in economic status.
    - perl4ever 6y ago
      Right now a lot more meals than usual are being prepared at home, and a lot of people who had jobs doing that are out of work. On the other hand, essentially the entire accounting system for the state hardest hit by coronavirus is run by "nonessential" employees, because that is what we are calling people who can work from home. Right now, there are definitely lots of people who can't work from home that are enormously essential in the ordinary sense. For instance, say you have a plumbing emergency. But, you know, your unemployment check is pretty essential too.

smadge 6y ago

> Businesses are paying exorbitant salaries and providing ping pong tables Businesses are paying market rate salaries to employees who generate them revenue. If anything engineers should be the ones questioning the exorbitant compensation and perks at the top of the org structure. > why shouldn't they have visibility into what's being done? Because they shouldn't be micromanaging. They should be setting high level goals and expectations and giving teams autonomy and trust. Intrusive surveillance and low level metrics create perverse incentives that detract from those high level goals.

rrrrrrrrrrrryan 6y ago
But how can they set goals without any visibility into what a team can typically accomplish in a given time period? How can they identify better performers and worse performers? I'm not saying agile is the right solution, (it probably isn't), but expecting higher-ups to fund a black-box team is kind of naive.
- kyuudou 6y ago
  Ye olde SV Scrum clip[1] "This just became a JOB..." -Gilfoyle [1]https://www.youtube.com/watch?v=oyVksFviJVE https://www.youtube.com/watch?v=oyVksFviJVE S01E05 Scrum scene I do like Agile, it's the typical problem of managers misusing it to micromanage, engage in useless metrics etc.
- jiggawatts 6y ago
  Measure the deliverable, not the deliverers. Reporting on random internal stuff instead of the actual problem at hand is the #1 problem I see with corporate reporting, everywhere. I see various combinations of people wasting time measuring: 1) The thing that is easy to measure, typically money or time. 2) The things they "understand", typically people for HR, compliance for legal, money for finance, etc... 3) The things their manager wants to know, no matter how irrelevant that is to executing their own job well. Meanwhile what they should be measuring is the qualities of the end-product or the overall external customer end result. It doesn't matter one iota if Bob the Developer Guy missed an internal 3-day deadline that John the Manager made up on the spot if the end product is a winner in the market and makes the users ecstatically happy to part with their money. This happens everywhere, with everybody. For an IT-centric example, the common one I see is: Helpdesk: "The users are complaining that the app is slow" Admins: "The load is only 10%, but fine, we'll add more capacity!" Helpdesk: "The app is still slow!" Admins: "The load is only 5%! They should have no reason to complain!" Do you see the issue? No, seriously: do you? Because practically nobody does, in my experience. Take a minute. What happened here is that the admins measured the thing that is easy for them to measure: the load. There's a cute little bar graph in VMware, or a chart in their network appliance, or whatever. What they should have been measuring is latency from the end-user perspective, but that's hard to measure and practically no product tells you this number out of the box. So their entire process, their reporting, their troubleshooting, their forms, requests, everything becomes focused on the thing that they can see and control. Even if it's pointless, ineffective, and basically a waste of everyone's time and effort. This happens with developers in exactly the same manner. Software quality is stupid hard to measure. Long term supportability is borderline impossible to measure without a time machine. Technical debt is hard to even explain to a manager, let alone keep tabs on in terms of numbers. So what's easy to measure? Time! Deadlines, sprints, release dates, etc... That's super easy. That's why inevitably the unimportant internal time metrics become critical to everybody, but the actually important metrics aren't even measured and become invisible to management until it's far too late.

jay_kyburz 6y ago

If outsiders want to see whats going on in an Agile team, all they need to do is run the "working software". They don't need to see all the ugly bits under the covers. Having working software is line two of the Manifesto. They can run it each week and see whats new. Even better, they can provide feedback on the working software and the team can then quickly respond to that feedback. In a week or two, when the outsider next looks at the working software they will see the software improved.

artsyca 6y ago
The quality of the software is the best metric of whether the process is working but management has no incentive to blame the process when it breaks down and every incentive to blame the people instead