Agile Manifesto - history page

The Manifesto - "Values" page - http://agilemanifesto.org/

The principles  - http://agilemanifesto.org/principles.html

and (!)

The history - http://agilemanifesto.org/history.html

• The "historian" - Jim Highsmith
• Agile term - Martin Fowler idea
• All - "delighted by the final phrasing" (Alistair Cockburn)
• Biggest debate .... the  location
• Purpose: "get all the lightweight method leaders in one room." (Robert C. Martin)
• Jim Highsmith: "The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology"

Why to read this history page? Values and principles are not enough?

In fact, you can find on this story of Jim Highsmith some very interesting stuff about Agile and directly from the source some motivations related to selection of these values and principles. Some examples below.

"We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes"

 Yes, you are a "traditionalist" and you like document, but ... you have a positive response to these questions:

• Do you keep your documentation updated, so its truth value it is true?
• How useful it is this documentation?
• The effort to keep the documentation update is too high?

 

"We plan, but recognize the limits of planning in a turbulent environment"

Read  first  (in the same page) the story of Kent Beck about a "Dilbertesque organization". You cannot make plans and then change the plan hypotheses and believe that will still work. The "turbulent environment" it is in fact the default for software development. The requirements will change? The solution are standardized?

Thank you Jim Highsmith for this page of history!

Uncle Bob quotes - We will not ship shit !

Under no circumstances ... We will not ship shit ! 

(Robert C. Martin (Uncle Bob) - Demanding Professionalism in Software Development )

Scrum: Stop saying methodology!

Often it is used the term methodology relative to the Scrum framework. Some says that these terms: method, methodology, process frameworks are equivalent. Maybe that could be true in common language and maybe not in specific domains as software development in particular, or for process management in general.
 

For Scrum,  it is better to listen the voice of its authors:

http://www.infoq.com/news/2010/08/kenschwaber-interview-part1

 >>>

Ken, the Scrum Guide does not say who defines the Sprint Goal. It also does not say who selects the person to be Scrum Master. It ALSO does not say who defines the super-important Sprint length (it is limited to 4 weeks of less, but the Guide does not say who decides the actual Sprint length.) In the current version, exactly how the Product Owner is selected is also somewhat vague.  Question: Is Scrum prescriptive enough? If so, why so and if not, why not?

What a fine line we walk between a framework and a methodology. A methodology tries to provide answers to all situations, to be prescriptive and complete. In doing so, of course, it would be so long and hard to parse as to be useless. All contingencies can never be posited or described. I’ve always erred on the side of brevity – let intelligent people find out the best approach, what works for them in their situation. Then they are free to change the approach when it is no longer appropriate.

The “black holes” that you describe above in Scrum would be easy for me to fill. However, I’d be filling them from my point of view, and the answers would become a methodology. As I find floundering in the holes, I try to fill them with Tips in the Scrum Guide, blog entries, videos, and even talks.

But I resist making the Scrum framework prescriptive. I hate methodologies.

>>> (Interview with Ken Schwaber, Part1 - by Dan Mezick on Aug 26, 2010)

"I hate methodologies" ! - Scrum was not intended to provide all the answers and the practitioners should find the best approach in the context . 

Anyway, the Scrum knowledge is organized in levels: the basic information could be find in the Scrum Guide.  Considering the amount o (and not necessary the content) there is few information in the Scrum Guide, but - in the same time - it is the most generic. More advanced knowledge could be found in other artifacts of the two authors: books, courses or as Ken Schwaber says blogs, videos, talks. Of course, this information is less generic, and sometime are even very specific case studies.

Another aspect is the engineering part - not explicitly specified in the Scrum, but if you read again, you can find some tips about aspects that need strong engineering practices. Jeff Sutherland helped Kent Beck on XP - Extreme Programming creation and has used from the beginning the engineering practices that are part of XP as pair-programming, refactoring and TDD (or A-TDD).  

Scrum is a lightweight framework, an Agile "method" that provide very generic aspects that helps to solve complex problems by offering some instruments to practically use the Inspect & Adapt  principle. Anything else you will need to add to the process remain at your decision in the specific context and according to professions rules.

 

Martin Fowler about Agility

Jeff Sutherland has launched a debate about definition of Agility (less then 100 chars)... And Martin Fowler has an answer:

Martin Fowler

@jeffsutherland (People-first > process-first) + (Adaptive planning > predictive planning) #Idefineagile

7:28 PM - 17 Jan 2014

(People-first > process-first) - yes, that is part of Agile Manifesto main values.

(Adaptive planning > predictive planning) - that is not explicitly in the Manifesto, but could be an inference from its principles. Long term projects need predictions...Small term projects mean adaptation. Of course, that does not match with the Waterfall mindset of some managers that want (claim) to use "agile" but, in fact, they continue their Waterfall practices.

Mastering Agile

Things of interest - simple "trick"

How can we find things of interest about Agile ? How can we master Agile? Here's a trick: let's find out which are the main areas of interest and performance for the authors of Agile Manifesto, the "founding fathers":

(my apologies for possible mistakes)

• Robert C. Martin (initiator of AM) -  Design principles for OOP, Clean Code, Software Craftsmanship Manifesto
• Martin Fowler - Refactoring, Patterns (Architecture, Design, Analysis), UML books, Technical Debt Quadrant
• Kent Beck - XP creator, TDD, jUnit, CRC cards
• Ward Cunningham - Portland Pattern Repository , WikiWikiWeb, the World's first wiki; Technical Debt definition; Also contributor to XP
• Jeff Sutherland - Scrum creator
• Ken Schwaber - Scrum creator
• Ron Jeffries- also founder of XP
• Alistair Cockburn - Effective Use Cases, Crystal methods, PM Declaration of interdependence
• Jim Highsmith - Adaptive Software Development
• Mike Beedle - Scrum consultant , applies Scrum and XP together
• Arie van Bennekum - Dynamic Systems Development Method
• James Grenning - invented Planning Poker
• Andrew Hunt - book author: The Pragmatic Programmer
• Jon Kern - co-authored "Java Design"
• Brian Marick - Agile testing 
• Steve Mellor - contribution to UML extension and MDA
• Dave Thomas - Co-author of  The Pragmatic Programmer 

See also http://agilemanifesto.org/authors.html

Topics by Numbers

Another "trick":  let's count the main themes to see what matters most:

• Software design: 14
• Agile methods & process:  10
• PM: 2
• Agile requirements: 2 

It is pretty simple to master Agile, right? Just learn all these things!

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.

Agile claims versus Agile Manifesto

There is a big problem with the Agile claims. Many of them are just claims, and there are close to a logical fraud. I recently had a similar experience - with the below report - where the main result was to just deeply annoy (!) tens of agile practitioners (or at least a third of them) with the Agile Manifesto.

"Mario Moreira reports his survey results. Most people who claim to be agile don't know the agile principles in the Agile Manifesto." - Jeff Sutherland

Here you can find this report and also I have extract some quotes.

http://cmforagile.blogspot.ro/2014/01/as-i-look-across-agile-landscape-i-am.html

"ThThe results were quite revealing and support my hypothesis.  Of the 109 Agile participants: 

• 59% knew 3 or more of the five Scrum events
• 11% knew 3 or more of the twelve Agile principles

I actually find these results quite astounding.  Could it really be true that only 11% of Agile professionals and enthusiasts could name just 3 Agile principles?  I don't mean they they memorize them but can provide at least the key words of the principle.  This means that 89% could only name 2 or less.  What makes this even more astonishing is that 67% could not name even a single Agile principle (and I did give credit to those who could name the key words of the principle - e.g., self-organizing,  frequent delivery, etc.). " - Mario Moreira

"Now do keep in mind, knowing the principles is just the first step and it doesn't make you Agile.  Next its time to live it.  But how do we expect to “be Agile” if our focus is so much more focused on the mechanics or “doing Agile”.   I would suggest that anyone who claims to be an Agile enthusiast ought to periodically bring their work back to the Agile values and principles.  Maybe its time to revisit the values and principles and understand what it really takes to be Agile." - Mario Moreira 

The main question - it is a kind of fraud to pretend to be something that is far away from your current abilities?

Survival with Scrum

This article (the bellow link) present a list of interesting, tough and unusual interview questions (mostly from significant and well known companies) and some associated suggested answers. I want to analyze this question and this suggested answer from an Agile & Scrum viewpoint.

http://www.businessinsider.com/17-odd-tech-interview-questions-2014-1

>>

5. "If you were on an island and could only bring three things, what would you bring?"

– Yahoo, Search Quality Analyst interview. More Yahoo interview questions.

Suggested answer: A knife, matches and duct tape. (Duct tape is good for everything.)

Read more: http://www.businessinsider.com/17-odd-tech-interview-questions-2014-1#ixzz2qgStVoWj

>>

The suggested answer seems to be smart and even cool. It is possible to produce a good impression during an interview. Anyway, I will propose another viewpoint: we have a problem and we need a solution.  Let use an Agile/Scrum manner to solve this problem.

First: What are the value & risks associated with the problem? 

Second: It is a clear-enough question?
Third: What is my expertise in this domain?

Well ... Very high value and very high risks - "to be or not to be". And what about the island: what kind of island? It is near to Greenland or to Madagascar? It is Ireland or a simple rock near Saint Helen?

The information & the knowledge related to this problem is not ready enough in order to give a clear answer (a solution).  We need to refine this knowledge until will be ready for the answer.

My suggested answer: "for a such high risks, high value and also vague problem, I need to gather more information about the inland (... requirements) and also more information about the possible survival solutions. It is totally unwise to give you an answer in a matter of seconds, minutes and even hours."

Agile B.C.

Le Serment des Horaces-  painting by Jacques-Louis David

 Divide et impera!

~650 B.C. The military conflict between city of Rome and city of Alba Longa was decided by direct confrontation of some young soldiers: three Horatii (Romans) and three Curatii (Albans). After battle begins <<two of the Romans fell, fatally wounded, one upon the other, while all three of the Albans were wounded.[…] and though no match for his enemies together, was ready to fight them one at a time.>> (Titus Liviu) ... and the remaining  Horatius was able slay them one by one.