Saturday, October 4, 2014

The True Corruption of Agile (Robert C. Martin)

"You can't have a culture without practices; and the practices you follow identify your culture."  
(Robert C. Martin) 

Please read this post "The True Corruption of Agile" from Robert C. Martin blog:

The above quote it is an answer to these statements (quotes from the same post):

Holub says:

"...agile is a culture, not a set of practices..."
Binstock amplifies:

"Whether a site is Agile or not depends on its culture. Does the culture support the personal values of the manifesto? If so, it's Agile, if not, then it's doing something else. So, indeed you could have a fully Agile site without TDD, continuous integration, or scrum. Likewise, you can have a site that uses all three practices, but cannot adapt to changes and is wholly inflexible in its work — so, not at all Agile."
 The answer of Martin continue (quote):

The biggest problem I have seen within the Agile movement is the elimination of the practices. One by one, over the years, the practices have been de-emphasized, or even stripped away. This loss of practice has diluted and changed the Agile culture into something that I don't recognize as Agile any more. It has been a shift away from excellence towards mediocrity, away from hard realities, towards feel-good platitudes.
It began with the notion that anyone could become a "master" of anything by sitting in a two day class and getting a piece of paper. Soon to follow was the dilution and eventual loss of the technical practices. This prompted Martin Fowler to publish his classic and definitive blog: Flaccid Scrum. Then came the emphasis of project management over craftsmanship and the rise of the soft skills (attitudes) over the hard skills (practices). 

The (Uncle Bob) conclusion is that you cannot have a culture outside a set of practices that are part of the professions, where both management and engineering culture is expressed with practices. Abandoning practices it is just a  "shift away from excellence towards mediocrity".
Binstock says that you could have full agile result also without significant practices such TDD, continuous and Scrum (related practices) , where all that count is to be adaptive to changes and being flexible in the work and the mentioned practices could not guarantee that.

Somehow, both are right, but Binstock example is not so good, because mentioned that you may have one case where... A better logic should be generic, not based on a possible example.

Yes, you could have not be enough adaptive with TDD, Continuous Integration and Scrum practices, but that because the number of indispensable practices is much bigger.
Yes, you could be adaptive without these three practices, but not for any case but only for some cases. Example: the Agile Manifesto promise to support late changes with good results it is mostly impossible without TDD. 

"Adaptive to change" - I have tried to define this capability reflected in a set of indispensable practices for engineering aspects in the post "A roadmap to an Agile Design" on (see ).

Agile could be a "mindset", but not acquired by two days course (that could help), but from hard work and deep experience with applying of engineering and management practices.  

A Declaration of Practice Independence (from Ivar Jacobson)

A Declaration of Practice Independence

We hold these truths to be self- evident, 
that all practices are created equal,  
that they are endowed by their Creator with certain unalienable Rights, 
that among these are life (constant evolution), liberty (method independence) and the pursuit of excellence.
 (Ivar Iacobson)


My thoughts about practices:
  • could and should be used outside the (original) methods
  • could and should be used even are not in some methods (the problem with Agile Design,  Clean Code and Clean Architecture - see )
  • modern methods such DAD - Disciplined Agile Delivery have a better and flexible approach about practices and offer guidance on selecting them in context
  • building process it is (also) about selecting practice in context
  • BUT ... there are some remaining questions. Do you know that are the remaining questions?

Wednesday, October 1, 2014

Agile Design - new site/blog -

Here are the reasons to dedicate a distinct site/blog to the problems and solutions related to Agile Design.

Agile software development make a strong promise to the customers – that will offer good results (sustainable, effective, efficient) for an adaptive context (quick, often and even late).
In most of the cases , the claimed Agile process does not keep the full promise, especially for toughest parts:
  • a sustainable,  long term collaboration with the customer
  • good response for late changes
The main reason is the lack of coverage of some aspects related to design. The teams does not use all necessary engineering practices, or in the worst case are considering only Agile management practices.

There must be a better way!

We need to define a set of indispensable design related practices and use them in order to to keep the promise. There must be an Agile Design, defined as an Adaptive Design and used to build Adaptive Products.

An introduction to Agile Design propsal could be found here: