8 ms·

Don't measure developers, measure projects

164 points by jeanlaf 8y ago

nixpulvis 8y ago
Getting secure connection warnings.
- daveslash 8y ago
  Maybe the author fixed it - I see no such warning (FireFox 63), but what did catch my eye was a 3.6 MB jpeg that took 16.3 seconds to load (25 Mbps connection) -- admittedly, haven't read the actual article yet.
  - jeanlaf 8y ago
    Oh let me check this! Sorry about that.
  - jeanlaf 8y ago
    Fixed!
edejong 8y ago
Don't automate what you can't first do manually. Your best developers might be helping, supporting, designing and architecting your next solution. One commit, one PR, might prove more valuable for your business than hundreds of other tickets closed. Remove the KPIs and talk to your team members in 1-on-1s regularly. Give responsibility and trust to your team, and they'll be self-empowering. Add KPIs and you'll take away their responsibility. Trust will be lost. Probability for innovative solutions will go down, your best developers will leave. It is all about trust and responsibility. Hire for team spirit, conscientiousness, communicative skills and diversity.
- garysahota93 8y ago
  Agreed! I couldn't have said it better myself. It's really hard to quantify all of this without remembering that no two metrics are interchangeable / comparable.
- closeparen 8y ago
  The phase of a project with a flood of PRs and closed tickets is the easy part. The real work is done before and after (planning and debugging), in people’s heads.
- zerop 8y ago
  I saw this happening. Putting metrics puts pressure and people wont innovate and leave. You can't be innovative when there are metrics on your head.
stcredzero 8y ago
A friend of mine was looking at the metrics for a project he was managing and saw that the bug rate of commits after 4pm was much higher. So then he introduced a new rule against committing after 4pm, resulting in a big drop in the bug rate. He chalked it up to less committing while fatigued and rushing to get things done to go home.
- not_kurt_godel 8y ago
  That's really interesting. Was there any drop in overall productivity/delivery pace as a result? There are definitely times when I wind up cranking out buggier-than-usual code later in the day/night to meet deadlines or get things done that otherwise wouldn't (at least, not on schedule). Sometimes when I timebox myself too much like that and it winds up dragging projects out days or weeks longer than they would have been had I not just blocked out a few hours to get the dang thing working and then cleaned it up afterwards; this is particularly true for complex projects where it can take a large portion of the day simply to build the mental context necessary to actually start executing on what needs to be done. If I cut myself off at a certain arbitrary time, the time spent building mental context earlier is totally wasted.
  - stcredzero 8y ago
    If I cut myself off at a certain arbitrary time, the time spent building mental context earlier is totally wasted. If what you have to remember to make a certain change means you have to keep 27 things in your head at once to avoid making bugs, you might want to consider re-organizing your code so this number is smaller.
itsdrewmiller 8y ago
I think the title of this post is great, but the body doesn't quite deliver. The best content I've found on this subject is this book: https://www.amazon.com/gp/product/0932633366 https://www.amazon.com/gp/product/0932633366 It talks about the different between informative and motivational metrics - the former being just for awareness while the latter being intended as explicit targets for employees. While it's easy to bleed the former into the latter, there's nothing inherently wrong with measuring game-able statistics as long as the incentive to muck with them is minimized. Easier said than done, but not impossible. The article is pretty dismissive of story counting, which is a semi-popular approach to estimation: https://martinfowler.com/bliki/StoryCounting.html https://martinfowler.com/bliki/StoryCounting.html (Anecdotally, we had someone look at our teams' previous sprints and found that # stories / sprint was more consistent than points per sprint over the time frame they reviewed. YMMV.) The focus on velocity-related metrics seems smart - Git Prime did some analysis on this and found that frequency of commits was a useful measure: https://blog.gitprime.com/prolific-engineers-take-small-bites-patterns-in-developer-impact/ https://blog.gitprime.com/prolific-engineers-take-small-bite... I don't see how these are any less game-able than klocs though.
- jeanlaf 8y ago
  Thanks for the book recommendation! Will definitely read it :). Concerning Gitprime, I completely agree with you. And they do say that the point is to game their metrics: https://help.gitprime.com/general/cant-you-just-game-the-metrics https://help.gitprime.com/general/cant-you-just-game-the-met...
djcapelis 8y ago
Noooooooo. All of these metrics are a mistake, don't measure any of them. Measure the things that actually matter about your product and whether or not it's getting better or worse. Measure outcomes. Only outcomes. Try and make sure your metrics capture the real outcomes and not just what you see in a lab. This usually means you need to use field data to get that information.
- zapita 8y ago
  In larger organizations it can be very difficult for team managers to measure business outcomes of their work directly. Talking to customers is a difficult process, if at all allowed. Information from customers percolates through many layers of support and sales staff, product managers, business stakeholders, project managers etc. By the time the information gets to you it is tainted by bias and politics. Not that it would have helped you much since your objectives are already set by your hierarchy, and again are focused on your ability to execute, not business outcomes. That may not sound like a very productive environment, but that is the environmental in which most of the world’s software is written. For those engineering managers that have to operate in it, measuring your ability to execute is the best you can do. You might as well do it correctly (which is hard). And if you’re one of the lucky few working in a less dystopian environment, don’t be too quick to gloat. Enjoy it while it lasts, you’re just one acquisition or reorganization away from joining the rest of us in corporate mediocrity.
  - djcapelis 8y ago
    I work for one of the world’s largest companies. If your organizational structure is a problem for connecting outcomes with engineering then it sounds like you’ve already found a great problem to solve and so go ahead and tackle that instead of spending time on bad metrics! (Full disclaimer: I am also currently working as one of those project managers you mentioned. If your project managers aren’t communicating clearly about how engineering impacts outcomes, find new project managers.)
    - zapita 8y ago
austincheney 8y ago
One thing I have noticed when working with juniors is that the wrong things are considered for story point estimation and those story points are the metric of success. Juniors tend to be overwhelmingly concerned with basic literacy. First its a "does it work" and then it graduates to "how to write the code". This often comprises thinking about tools, frameworks, dependencies, and code style. These aren't deep problems that moves a business forward. These are competency problems that keeps a person employed. This is a distraction that consumes developers with busy work instead of thinking and planning about how to make a product better or how to release faster. Worse still, too much emphasis on the particulars around the how of it can blow out a 30 minute task to a 2-5 day task with all the unnecessary scaffolding and extra process. This is particularly frustrating when realizing these concerns can be immediately eliminated when the proper automation is in place. It is possible to really get good at spinning on mouse wheels and cranking out those stories a little bit faster, but it still isn't moving the business forward. Nothing forces out strong developers faster than cliches like: "That is the framework way" or "You're reinventing a wheel". Some better metrics to really measure real world success: 1. does the change solve a business problem 2. does it pass the project automation 3. does it reduce total code instructions 4. does it close out defects 5. reduced execution time 6. improvements to project automation (faster developers) 7. improvements to documentation Once the proper metrics are in place the concerns of the juniors are addressed economically. For example, if reducing instruction count is important the code gets leaner and the how of it shifts from code style to leaner code. Code style is important because developers need improved literacy from uniform code expression, but once the goal of expression is leaner code the uniformity shifts from expressive style to optimization concerns.
- ascar 8y ago
  I'm not sure what you mean with "reducing total code instructions" and "lean code", but I'm not sold on the idea of making code less readable which often happens when you try to reduce code by being smart. Reading code is mostly way harder than writing it, especially if you read code from someone else. Optimizing for readability is the game changer for maintainability. * Use expressive function and variable names. * Have clear consistent structure across your project(s). * Use simple code where possible. * Do not write one-liners that do multiple transformations. Each line should have one purpose. * Document design decisions in code. Don't document "what" your code does, that should be readable by itself, but why you made the decision to do it like that. * Documentation library style comments for complicated functions helps a ton to know what the function is supposed to do. * Add tests that specify the expected behavior. This not only helps when changing code, but also when reading. It's not readable code XOR documentation, it's both. Readable code is the "what", documentation is the "why". Even if the docs get outdated, the why can still be insightful. Non of the above suggestions usually reduces code, but it will help everyone else, including future-you in 6-months, to work with your code.
deleted 8y ago
[deleted]
quanticle 8y ago
Of the metrics listed, the only one I will say never to use is lines of code. As a very wise manager told me, "Code is a liability. Functionality and business value are assets." Measuring developer productivity by looking at how many lines of code they've written is like measuring the health of a business by how much money it's spending. If you can delete code and retain the same level of functionality (for example, because you found a library that will automate much of the task), then that's a huge win. Every piece of code that the team writes is one more thing that has to be unit tested, integration tested, documented, and maintained in the face of future changes. If they can offload that work to a library, or find a way to accomplish the same task by using existing code or by reconfiguring the application, that's almost always preferable to writing new code to accomplish a particular business need. Of course, one can go too far in the other direction. It's easy to fetishize using external libraries for everything (like we see so often in the JS ecosystem). But that's where I would argue that the analogy of treating code like money shines. Sometimes it is worth spending money to have something custom made for your business, rather than buying an off-the-shelf component. Similarly, sometimes it is worth writing code to do something custom, rather than integrating a third party library, or reconfiguring an existing application. But that choice should be consciously made. Rewarding developers for lines of code written moves that choice out of the realm of conscious decision-making and into the realm of reflex. They get paid for more lines of code, so they're always going to reach for the solution that results in more lines of code, regardless of whether that code is necessary or appropriate.
- jeanlaf 8y ago
  Completely agree! Love the quote "Code is a liability. Functionality and business value are assets."
  - scarejunba 8y ago
    The Goal has a bunch of insights translatable to software engineering. This is one of them.
    - dwd 8y ago
abernard1 8y ago
> If you don’t include story points or some equivalent, this might be the most misleading metric you could use. I'm sorry, but if you think "story points" is something useful, your organization is already doomed. Story points is an inflationary currency. When your developers realize that somebody important in the company cares about said currency, they will make sure that their work has more of these "story points" in "sprint planning".
- skybrian 8y ago
  Okay, how does this doom a project? It's just an arbitrary score to begin with, so what's wrong with inflation?
  - abernard1 8y ago
    Because now "real" velocity goes down. There's a negative Pavlovian reaction developers have every sprint when 1) "commitment" was not achieved, or 2) story points decreased. To avoid that pain, developers will pad points. This means that when things go according to plan, large sections of a sprint will have no work or people will try to appear busy. The easiest way to avoid that gamesmanship is to not measure things that don't matter, which is all inputs. What matters is outcomes, which can be in the form of money, usage, satisfaction, etc.
    - skybrian 8y ago
      I've only worked on an XP project once, but if we finished early, we either did some refactoring or pulled down another card and started on the next task. You do need some time now and then for refactoring and that's how we did it. Not everything needs to be formally estimated and scheduled. Story points are supposed be a tool to help management with realistic scheduling, not a way to push developers to work as fast as possible. If there's a lack of trust between engineering and management, it sounds like you have bigger problems.
      - abernard1 8y ago
ausjke 8y ago
Is Agile solving this problem now? or has Agile gotten out of fashion? * release often, release early, each release should function though with less features. * break large goal to small steps, one step at a time. * sprint every 2 weeks or 4 weeks. * 15-min stand-up every other day * etc,etc I read some agile books in the past, and now I'm experiencing real Agile in sw development for the first time, so far I found it is quite effective comparing to my past projects, assuming you have some great scrum master and project-owner that are really good at the balance of arts.
- wpietri 8y ago
  If people actually do it, it helps a lot. In my experience, if business stakeholders are seeing real value shipped to customers every week (or 2 if you must) then they don't get very antsy. Especially so if they are using a release-early, release-often approach to the product, where they see a project as an opportunity to explore what customers really want. The problem starts to come in when the feedback loops are long. If they ask for something in January and don't see results in June, then they've got 6 months to wig out. And one of the ways they'll try to manage their fear is by getting up in developers' business by imposing all sorts of metrics.
  - ausjke 8y ago
    in our case it's a long term internal project, it's embedded system development, we release bi-weekly internally before it reaches 1.0 for customers. embedded product is notoriously hard to manage and I found Agile process actually helped quite a bit, via Scrum's 'story points' method.
- Jtsummers 8y ago
  First, Agile is a collection of ideas and principles, and not a monolithic thing. Scrum (what you mostly describe) does not address this, really. Except that it attempts to reduce metrics down to a primary metric (there are others): Story Points. These are the primary concern of a Scrum team, and are developed by the team members as an estimate of the size of the stories (tasks) as they see them. These are not given by anyone else. These are not used by anyone else. The team then evaluates themselves (if they do this correctly) by constructing a control chart [0] to see how they're performing. If they trend down, they identify the cause and share the reason with other teams so that others with a similar cause can address it more readily. If they trend up, they identify the cause and share so that others can attempt to duplicate the success. Scrum does not address how to do personnel performance evaluations so it doesn't stop management from trying to use metrics for the purposes described in this article. For example, story points (if used as an evaluation metric for personnel) become useless as people will just inflate their numbers in a continual game of oneupmanship. At which point a large amount of the value of Scrum is lost. The Lean school of Agile is a philosophical descendant of Deming's work in Japan post WWII and the Toyota Production System (called Lean as it spread). This school of thought does address the issue discussed in the article in that Deming's views have you reducing your focus on individual performance and increasing focus on performance of teams and projects (title of the article is related to this). Deming and others recognize that the system in which work is performed effects the outcome more than the workers themselves (NB: His focus was largely on manufacturing, but this works in service industries and to some extent in our discipline as well). Since the view in that school is on the system, it does address the problems described in the article (if you get management to understand it). So by focusing on the project level (really you should probably go higher, department or even enterprise level) you can understand where problems are occurring, where there is waste worth cutting or addressing, etc. That said, I do not recall seeing some of those points I made (gathered from Deming and other sources) in any of the books I've read on Lean as it relates to software. It could just be that I have forgotten or missed that information (may have glossed over it as I had already internalized it) or was in sources that I haven't read yet. [0] https://en.wikipedia.org/wiki/Control_chart https://en.wikipedia.org/wiki/Control_chart
deleted 8y ago
[deleted]

164 points by jeanlaf 8y ago

nixpulvis 8y ago

Getting secure connection warnings.

daveslash 8y ago
Maybe the author fixed it - I see no such warning (FireFox 63), but what did catch my eye was a 3.6 MB jpeg that took 16.3 seconds to load (25 Mbps connection) -- admittedly, haven't read the actual article yet.
- jeanlaf 8y ago
  Oh let me check this! Sorry about that.
- jeanlaf 8y ago
  Fixed!

edejong 8y ago

Don't automate what you can't first do manually. Your best developers might be helping, supporting, designing and architecting your next solution. One commit, one PR, might prove more valuable for your business than hundreds of other tickets closed. Remove the KPIs and talk to your team members in 1-on-1s regularly. Give responsibility and trust to your team, and they'll be self-empowering. Add KPIs and you'll take away their responsibility. Trust will be lost. Probability for innovative solutions will go down, your best developers will leave. It is all about trust and responsibility. Hire for team spirit, conscientiousness, communicative skills and diversity.

garysahota93 8y ago
Agreed! I couldn't have said it better myself. It's really hard to quantify all of this without remembering that no two metrics are interchangeable / comparable.
closeparen 8y ago
The phase of a project with a flood of PRs and closed tickets is the easy part. The real work is done before and after (planning and debugging), in people’s heads.
zerop 8y ago
I saw this happening. Putting metrics puts pressure and people wont innovate and leave. You can't be innovative when there are metrics on your head.

stcredzero 8y ago

A friend of mine was looking at the metrics for a project he was managing and saw that the bug rate of commits after 4pm was much higher. So then he introduced a new rule against committing after 4pm, resulting in a big drop in the bug rate. He chalked it up to less committing while fatigued and rushing to get things done to go home.

not_kurt_godel 8y ago
That's really interesting. Was there any drop in overall productivity/delivery pace as a result? There are definitely times when I wind up cranking out buggier-than-usual code later in the day/night to meet deadlines or get things done that otherwise wouldn't (at least, not on schedule). Sometimes when I timebox myself too much like that and it winds up dragging projects out days or weeks longer than they would have been had I not just blocked out a few hours to get the dang thing working and then cleaned it up afterwards; this is particularly true for complex projects where it can take a large portion of the day simply to build the mental context necessary to actually start executing on what needs to be done. If I cut myself off at a certain arbitrary time, the time spent building mental context earlier is totally wasted.
- stcredzero 8y ago
  If I cut myself off at a certain arbitrary time, the time spent building mental context earlier is totally wasted. If what you have to remember to make a certain change means you have to keep 27 things in your head at once to avoid making bugs, you might want to consider re-organizing your code so this number is smaller.

itsdrewmiller 8y ago

I think the title of this post is great, but the body doesn't quite deliver. The best content I've found on this subject is this book: https://www.amazon.com/gp/product/0932633366 https://www.amazon.com/gp/product/0932633366 It talks about the different between informative and motivational metrics - the former being just for awareness while the latter being intended as explicit targets for employees. While it's easy to bleed the former into the latter, there's nothing inherently wrong with measuring game-able statistics as long as the incentive to muck with them is minimized. Easier said than done, but not impossible. The article is pretty dismissive of story counting, which is a semi-popular approach to estimation: https://martinfowler.com/bliki/StoryCounting.html https://martinfowler.com/bliki/StoryCounting.html (Anecdotally, we had someone look at our teams' previous sprints and found that # stories / sprint was more consistent than points per sprint over the time frame they reviewed. YMMV.) The focus on velocity-related metrics seems smart - Git Prime did some analysis on this and found that frequency of commits was a useful measure: https://blog.gitprime.com/prolific-engineers-take-small-bites-patterns-in-developer-impact/ https://blog.gitprime.com/prolific-engineers-take-small-bite... I don't see how these are any less game-able than klocs though.

jeanlaf 8y ago
Thanks for the book recommendation! Will definitely read it :). Concerning Gitprime, I completely agree with you. And they do say that the point is to game their metrics: https://help.gitprime.com/general/cant-you-just-game-the-metrics https://help.gitprime.com/general/cant-you-just-game-the-met...

djcapelis 8y ago

Noooooooo. All of these metrics are a mistake, don't measure any of them. Measure the things that actually matter about your product and whether or not it's getting better or worse. Measure outcomes. Only outcomes. Try and make sure your metrics capture the real outcomes and not just what you see in a lab. This usually means you need to use field data to get that information.

zapita 8y ago
In larger organizations it can be very difficult for team managers to measure business outcomes of their work directly. Talking to customers is a difficult process, if at all allowed. Information from customers percolates through many layers of support and sales staff, product managers, business stakeholders, project managers etc. By the time the information gets to you it is tainted by bias and politics. Not that it would have helped you much since your objectives are already set by your hierarchy, and again are focused on your ability to execute, not business outcomes. That may not sound like a very productive environment, but that is the environmental in which most of the world’s software is written. For those engineering managers that have to operate in it, measuring your ability to execute is the best you can do. You might as well do it correctly (which is hard). And if you’re one of the lucky few working in a less dystopian environment, don’t be too quick to gloat. Enjoy it while it lasts, you’re just one acquisition or reorganization away from joining the rest of us in corporate mediocrity.
- djcapelis 8y ago
  I work for one of the world’s largest companies. If your organizational structure is a problem for connecting outcomes with engineering then it sounds like you’ve already found a great problem to solve and so go ahead and tackle that instead of spending time on bad metrics! (Full disclaimer: I am also currently working as one of those project managers you mentioned. If your project managers aren’t communicating clearly about how engineering impacts outcomes, find new project managers.)
  - zapita 8y ago

austincheney 8y ago

One thing I have noticed when working with juniors is that the wrong things are considered for story point estimation and those story points are the metric of success. Juniors tend to be overwhelmingly concerned with basic literacy. First its a "does it work" and then it graduates to "how to write the code". This often comprises thinking about tools, frameworks, dependencies, and code style. These aren't deep problems that moves a business forward. These are competency problems that keeps a person employed. This is a distraction that consumes developers with busy work instead of thinking and planning about how to make a product better or how to release faster. Worse still, too much emphasis on the particulars around the how of it can blow out a 30 minute task to a 2-5 day task with all the unnecessary scaffolding and extra process. This is particularly frustrating when realizing these concerns can be immediately eliminated when the proper automation is in place. It is possible to really get good at spinning on mouse wheels and cranking out those stories a little bit faster, but it still isn't moving the business forward. Nothing forces out strong developers faster than cliches like: "That is the framework way" or "You're reinventing a wheel". Some better metrics to really measure real world success: 1. does the change solve a business problem 2. does it pass the project automation 3. does it reduce total code instructions 4. does it close out defects 5. reduced execution time 6. improvements to project automation (faster developers) 7. improvements to documentation Once the proper metrics are in place the concerns of the juniors are addressed economically. For example, if reducing instruction count is important the code gets leaner and the how of it shifts from code style to leaner code. Code style is important because developers need improved literacy from uniform code expression, but once the goal of expression is leaner code the uniformity shifts from expressive style to optimization concerns.

ascar 8y ago
I'm not sure what you mean with "reducing total code instructions" and "lean code", but I'm not sold on the idea of making code less readable which often happens when you try to reduce code by being smart. Reading code is mostly way harder than writing it, especially if you read code from someone else. Optimizing for readability is the game changer for maintainability. * Use expressive function and variable names. * Have clear consistent structure across your project(s). * Use simple code where possible. * Do not write one-liners that do multiple transformations. Each line should have one purpose. * Document design decisions in code. Don't document "what" your code does, that should be readable by itself, but why you made the decision to do it like that. * Documentation library style comments for complicated functions helps a ton to know what the function is supposed to do. * Add tests that specify the expected behavior. This not only helps when changing code, but also when reading. It's not readable code XOR documentation, it's both. Readable code is the "what", documentation is the "why". Even if the docs get outdated, the why can still be insightful. Non of the above suggestions usually reduces code, but it will help everyone else, including future-you in 6-months, to work with your code.

deleted 8y ago

[deleted]

quanticle 8y ago

Of the metrics listed, the only one I will say never to use is lines of code. As a very wise manager told me, "Code is a liability. Functionality and business value are assets." Measuring developer productivity by looking at how many lines of code they've written is like measuring the health of a business by how much money it's spending. If you can delete code and retain the same level of functionality (for example, because you found a library that will automate much of the task), then that's a huge win. Every piece of code that the team writes is one more thing that has to be unit tested, integration tested, documented, and maintained in the face of future changes. If they can offload that work to a library, or find a way to accomplish the same task by using existing code or by reconfiguring the application, that's almost always preferable to writing new code to accomplish a particular business need. Of course, one can go too far in the other direction. It's easy to fetishize using external libraries for everything (like we see so often in the JS ecosystem). But that's where I would argue that the analogy of treating code like money shines. Sometimes it is worth spending money to have something custom made for your business, rather than buying an off-the-shelf component. Similarly, sometimes it is worth writing code to do something custom, rather than integrating a third party library, or reconfiguring an existing application. But that choice should be consciously made. Rewarding developers for lines of code written moves that choice out of the realm of conscious decision-making and into the realm of reflex. They get paid for more lines of code, so they're always going to reach for the solution that results in more lines of code, regardless of whether that code is necessary or appropriate.

jeanlaf 8y ago
Completely agree! Love the quote "Code is a liability. Functionality and business value are assets."
- scarejunba 8y ago
  The Goal has a bunch of insights translatable to software engineering. This is one of them.
  - dwd 8y ago

abernard1 8y ago

> If you don’t include story points or some equivalent, this might be the most misleading metric you could use. I'm sorry, but if you think "story points" is something useful, your organization is already doomed. Story points is an inflationary currency. When your developers realize that somebody important in the company cares about said currency, they will make sure that their work has more of these "story points" in "sprint planning".

skybrian 8y ago
Okay, how does this doom a project? It's just an arbitrary score to begin with, so what's wrong with inflation?
- abernard1 8y ago
  Because now "real" velocity goes down. There's a negative Pavlovian reaction developers have every sprint when 1) "commitment" was not achieved, or 2) story points decreased. To avoid that pain, developers will pad points. This means that when things go according to plan, large sections of a sprint will have no work or people will try to appear busy. The easiest way to avoid that gamesmanship is to not measure things that don't matter, which is all inputs. What matters is outcomes, which can be in the form of money, usage, satisfaction, etc.
  - skybrian 8y ago
    I've only worked on an XP project once, but if we finished early, we either did some refactoring or pulled down another card and started on the next task. You do need some time now and then for refactoring and that's how we did it. Not everything needs to be formally estimated and scheduled. Story points are supposed be a tool to help management with realistic scheduling, not a way to push developers to work as fast as possible. If there's a lack of trust between engineering and management, it sounds like you have bigger problems.
    - abernard1 8y ago

ausjke 8y ago

Is Agile solving this problem now? or has Agile gotten out of fashion? * release often, release early, each release should function though with less features. * break large goal to small steps, one step at a time. * sprint every 2 weeks or 4 weeks. * 15-min stand-up every other day * etc,etc I read some agile books in the past, and now I'm experiencing real Agile in sw development for the first time, so far I found it is quite effective comparing to my past projects, assuming you have some great scrum master and project-owner that are really good at the balance of arts.

wpietri 8y ago
If people actually do it, it helps a lot. In my experience, if business stakeholders are seeing real value shipped to customers every week (or 2 if you must) then they don't get very antsy. Especially so if they are using a release-early, release-often approach to the product, where they see a project as an opportunity to explore what customers really want. The problem starts to come in when the feedback loops are long. If they ask for something in January and don't see results in June, then they've got 6 months to wig out. And one of the ways they'll try to manage their fear is by getting up in developers' business by imposing all sorts of metrics.
- ausjke 8y ago
  in our case it's a long term internal project, it's embedded system development, we release bi-weekly internally before it reaches 1.0 for customers. embedded product is notoriously hard to manage and I found Agile process actually helped quite a bit, via Scrum's 'story points' method.
Jtsummers 8y ago
First, Agile is a collection of ideas and principles, and not a monolithic thing. Scrum (what you mostly describe) does not address this, really. Except that it attempts to reduce metrics down to a primary metric (there are others): Story Points. These are the primary concern of a Scrum team, and are developed by the team members as an estimate of the size of the stories (tasks) as they see them. These are not given by anyone else. These are not used by anyone else. The team then evaluates themselves (if they do this correctly) by constructing a control chart [0] to see how they're performing. If they trend down, they identify the cause and share the reason with other teams so that others with a similar cause can address it more readily. If they trend up, they identify the cause and share so that others can attempt to duplicate the success. Scrum does not address how to do personnel performance evaluations so it doesn't stop management from trying to use metrics for the purposes described in this article. For example, story points (if used as an evaluation metric for personnel) become useless as people will just inflate their numbers in a continual game of oneupmanship. At which point a large amount of the value of Scrum is lost. The Lean school of Agile is a philosophical descendant of Deming's work in Japan post WWII and the Toyota Production System (called Lean as it spread). This school of thought does address the issue discussed in the article in that Deming's views have you reducing your focus on individual performance and increasing focus on performance of teams and projects (title of the article is related to this). Deming and others recognize that the system in which work is performed effects the outcome more than the workers themselves (NB: His focus was largely on manufacturing, but this works in service industries and to some extent in our discipline as well). Since the view in that school is on the system, it does address the problems described in the article (if you get management to understand it). So by focusing on the project level (really you should probably go higher, department or even enterprise level) you can understand where problems are occurring, where there is waste worth cutting or addressing, etc. That said, I do not recall seeing some of those points I made (gathered from Deming and other sources) in any of the books I've read on Lean as it relates to software. It could just be that I have forgotten or missed that information (may have glossed over it as I had already internalized it) or was in sources that I haven't read yet. [0] https://en.wikipedia.org/wiki/Control_chart https://en.wikipedia.org/wiki/Control_chart

deleted 8y ago

[deleted]