From Agile Software Development’s “Micromanagement in Agile/Scrum”:

The sad or not so sad truth is that agile methods are not aimed at maximizing the development team productivity. It is one of the welcome side effects that can happen, but that is not the grand goal. One can even say that the agile doesn’t care about the development team productivity at all (you anyway cannot measure it properly). What agile is focused on is the speed of the business value realization.

Sounds like me over at “Development Acceleration: The Second Derivative of Functionality“, where I defined “functionality” as business value realization:

Functionality is the application of technology to a business solution. Adding a new method is not functionality — even if it enables the code to do something it didn’t do before — until you apply that code to solve a business problem. Note that a given piece of code can provide a lot of functionality by playing in many different roles: the classic example of this would be the POSIX utilities like cron and grep. On the other hand, functionality can be lost even in a stable code base by shifting business expectations: “Until that code is changed so it stops doing X and does Y instead, it’s worthless.” / “But you spec’ed it out at X!” / “Yup. But now we need Y.”

My only beef with the original statement is that I’d say business value realization is the very definition of productivity in the business world. What is the team producing with all their productivity if they aren’t adding business value?

Both articles are definitely worth a read, if you haven’t.

Popularity: 9% [?]

Trackback URI | Comments RSS