Key Chord Song is a blog that discusses the key, lyrics, song, download, all information related to copyright is the artist and creator. All songs on the responsibility of the risk of piracy by users. If there are any questions, please contact our keys or send mail to eldiana@gmail.com

Sunday, January 26, 2014

Acceleration, schmeleration. Scott Ambler misses the point...

Through this post on InfoQ I learned that Scott Ambler is writing about productivity in Agile and how to measure it. He comes up with an interesting concept, that of acceleration.

Anyone familiar with statistical process control knows that a process does not have "acceleration" by itself. A process is either under statistic process control (ie churning out about the same amount of output per unit of time, within an acceptable variation) or it is not (ie the output is not reliable).

If a process's output is changing outside the control limits (ie not in statistical process control that actually means that the process is not under statistic process control. When that happens it is due to either one of two:

  • Common cause - This is a cause that is known and happens repeatedly (e.g. accumulated technical debt in a way that can be anticipated).
  • Special cause - Something totally out of left field that cannot be predicted.


If the velocity of the team is decreasing constantly (to the point that you can measure acceleration as Scott proposes) then you are in the presence of a common cause (ie predictable cause that impacts velocity). If that is the case you know that it's not the team that is to blame, it is the system in which the team is working that is causing the decreased velocity.

Scott misses the point completely, when it comes to processes, if you can "predict" the acceleration in velocity then you can do something about it. However, you do have to work at it, you need to investigate the systemic causes for the velocity to decrease and identify the root cause that, being solved, can change the system's behavior. This is not necessarily easy or quick...

In practice this means that every single team out there can improve their productivity (and should) by looking at their velocity, seeing if it is within the statistic control limits and acting on it. If the velocity is in control (as in statistic control) you can improve it by changing the process (the whole process, not just the team's sprint-process). If your velocity is not in control then you need to eliminate the "special causes".

What does this all mean? It means that instead of selling the idea of
"pricing" velocity increases for an Agile team (or any other team) Scott should be trying to tell people about the consequences of actually knowing whether your velocity is increasing/decreasing or it is stable.


Here's what really matters:

  • If your velocity is stable (in control) the only way to improve it is to change the process (do a proper retrospective, identify root causes and then act -- the old PDCA). Remember that the "whole" process influences the team's velocity, not just what you do within a sprint (requirements, production, etc. should be looked at also).
  • If your velocity is not stable (not in control) then you should start by analyzing the reasons for it's oscillation and start solving those. These tend to be random events that happen in an unpredictable fashion (e.g. a developer forgot to submit one change to the VCS before testing started).
Through this post on InfoQ I learned that Scott Ambler is writing about productivity in Agile and how to measure it. He comes up with an interesting concept, that of acceleration.

Anyone familiar with statistical process control knows that a process does not have "acceleration" by itself. A process is either under statistic process control (ie churning out about the same amount of output per unit of time, within an acceptable variation) or it is not (ie the output is not reliable).

If a process's output is changing outside the control limits (ie not in statistical process control that actually means that the process is not under statistic process control. When that happens it is due to either one of two:
  • Common cause - This is a cause that is known and happens repeatedly (e.g. accumulated technical debt in a way that can be anticipated).
  • Special cause - Something totally out of left field that cannot be predicted.


If the velocity of the team is decreasing constantly (to the point that you can measure acceleration as Scott proposes) then you are in the presence of a common cause (ie predictable cause that impacts velocity). If that is the case you know that it's not the team that is to blame, it is the system in which the team is working that is causing the decreased velocity.

Scott misses the point completely, when it comes to processes, if you can "predict" the acceleration in velocity then you can do something about it. However, you do have to work at it, you need to investigate the systemic causes for the velocity to decrease and identify the root cause that, being solved, can change the system's behavior. This is not necessarily easy or quick...

In practice this means that every single team out there can improve their productivity (and should) by looking at their velocity, seeing if it is within the statistic control limits and acting on it. If the velocity is in control (as in statistic control) you can improve it by changing the process (the whole process, not just the team's sprint-process). If your velocity is not in control then you need to eliminate the "special causes".

What does this all mean? It means that instead of selling the idea of
"pricing" velocity increases for an Agile team (or any other team) Scott should be trying to tell people about the consequences of actually knowing whether your velocity is increasing/decreasing or it is stable.


Here's what really matters:

  • If your velocity is stable (in control) the only way to improve it is to change the process (do a proper retrospective, identify root causes and then act -- the old PDCA). Remember that the "whole" process influences the team's velocity, not just what you do within a sprint (requirements, production, etc. should be looked at also).
  • If your velocity is not stable (not in control) then you should start by analyzing the reasons for it's oscillation and start solving those. These tend to be random events that happen in an unpredictable fashion (e.g. a developer forgot to submit one change to the VCS before testing started).

Untuk mencari langsung semua chord dan lirik lagu gak muter muter,, ketik nama judul lagu / penyanyi di kolom pencarian Custom Google di bawah ini / di kanan atas untuk pencarian hasil yang lebih akurat


"All Copyright violations will be processed by appropriate legal regulations in each country"
Thank you for visiting music blogs

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Kunci Lagu Chord adalah blog yang membahasa kunci, lirik, lagu, download, segala informasi terkait dang pembajakan lagu di tanggung resiko oleh pengguna, materi dan konten di blog ini semata - mata hanya untuk hiburan saja.