The Story of Agile Manifesto

You can find the full article here:

http://www.informit.com/articles/article.aspx?p=1743276

>>>
InformIT: You were a co-author of the Agile Manifesto in 2001. What drew you to the gathering?

Bob: In 2000 I asked Martin Fowler to lunch to talk about the idea of a "Lightweight Process Summit." We were both part of the Extreme Programming movement, but we had seen that there were several other similar processes, most notably SCRUM, FDD, DSDM, and Crystal. We thought it would be a good idea to get the advocates of all those processes together with other industry leaders to see if there wasn't some way to find and define common ground. I suggested to Martin at the time that we might be able to create some kind of manifesto. He and I put an invitation list together. I composed the invitation and sent it out. After that the process took on a life of its own.

>>> ("Ten Years Of Agile: An Interview with Robert C. "Uncle Bob" Martin")

The idea (and the initiative) of a "Lightweight Process Summit" and of the manifesto that could define the common ground of that kind of movement belong to Robert C. Martin. "Uncle Bob" and Martin Fowler have created also the invitation list... The resulted manifesto is quite outstanding, at least for the ones that have good experience with software development and could serve as guidance for every practitioner.

Yes, we can say that all those methods are "implementing" these principles, but the great thing is that it was first the demonstration: methods and practices resulted from experience and proven to be working. This "theory" (the values and associated principles) are just the abstraction of real experience.

Thank you, Uncle Bob! :)

Note: "The Manifesto of Softwarecraftsmanship" has the same creator.

Hyper-productivity - just a short run ?

The Scrum marketing claims Hyper-Productivity. Sometime is true, sometime it is not. That depends on who make that claim...Which is the best way to validate that? We can measure, for example, the team velocity for a period of few months. It is that a correct approach?

Maybe the most know and severe problem in software development is the accumulation of the undesired complexity - Technical Debt. The main consequence of a such debt is the deterioration - in time - of the overall productivity and quality. 

Short "hyper-productive" runs with a lot of accumulated debt it is not Agile and it is not Scrum. Remember the principle from Agile Manifesto that require "sustainable development": "The sponsors, developers, and users should be able to maintain a constant pace indefinitely.". Scrum suppose that you will assess your work progress using the criteria of "Done": no other work is necessary on that product part, and that include very few Technical Debt.

Anyway, this kind of  "shortness of breath" it is very common and we must be able to identify and address the root causes. One cause it is the lack of skills of the involved team of developers, but another is related to the management.

"So how can you incent a Scrum team to not make a mess?"

This is a very good question, proposed by Robert C. Martin, in the article "The Land that Scrum Forgot"  that could be found here (with a forward by Mike Cohn):

http://www.scrumalliance.org/community/articles/2010/december/the-land-that-scrum-forgot/

Spoiler (from the article): "If the team goes fast and stays clean, then there is a reward!"

Usually only the project viewpoint it is the of interest for the management, because is focused on short term results. Anyway, the overall business should remain steady, and we should be interested on the product internal state, the amount of the accumulated undesired complexity.

The Scrum proposed by Jeff Sutherland it is Hyper-Productive (!), because in the same package we will found the requirement for technical excellence and outstanding enginnering practices such as TDD. For a such performance you need to read more than Scrum Guide and you need more others Agile skills and knowledge.