(luKa)

After hands-on experience with Agile practices, working in Agile environments and attending conferences with Agile experts, I have annotated what I think could be the dimensions of Agile that detail and expand the original motto Embrace Change:

• dealing with uncertainty
  
  
• managing the unexpected
  
  
• recognizing the unknowns
  
  
• exploring through discovery & invention
  
  
• balancing anticipation & adaptation
  
  
• combining instinct & thought & experience (as learning from action)
  
  
• making sense in complex contexts
  
  
• amplify the emergence of beneficial behaviors and outcomes
  
  
• continuing the quest for craftsmanship

Dimensions are intended here in the sense that the values and principles in the Agile Manifesto, the values and principles and practices of XP, the 3 legs the 3 artifacts the 3 roles and the 3 meetings of Scrum as well as the foundations the roles and the activities and artifacts of OpenAgile and the values and the principles of Lean can all be directly related and derilved from one or more dimensions.


Can you suggest other dimensions?

10 years have passed, bringing successes [1], and bringing new challenges for the next 10 years [2][3][4][5].


Also now, Agile is mainstream.
And this can be the major change after these 10 years.
Indeed this is something that cannot be changed, controlled or forced into a predefined plan.
Instead is something to welcome and to adapt to, searching for the best possible outcomes.


This event, Agile that from a minority is turned into a mainstream approach, also has the potential to be a disruptive event, because it can change the game and this could fade away most of the original Agile ideas.
For example the lack of openness could lead to fundamentalist adherence to misunderstood rules and could cause the loss of the expected benefit/advantages of Agile.  And the loss of the key Agile foundations could lead to a fictional representation of Agile that doesn't produce real benefits/advantages and that justify fake evolutions that are founded on misunderstandings and misinterpretations. Nat Pryce expressed the latter idea with these words: In software "X improves upon Y" seems to mean "X improves upon the bit of Y that the author of X learned about".



For what I understand, when a minority turn mainstream, to survive and to evolve needs to preserve the most valuable traits of its identity and at the same time needs to be open to changes and contaminations, be curious, exploit diversity [6] be inclusive and build bridges.  A prerequisite for this is to deepen and strength the understanding of the key valuable factors of Agile, its identity behind rituals and conventions, and to spread the key knowledge and key practices, make them resilient to the ongoing Mash-up and crossover that is happening with lot of contributions from different sources, fields, people, background. And be open to let all the others non essentials/key things go.



How ?


Here I try to propose a possible answer, for example I would like to read more books/articles and see more discussions and teams deepening

• more about Agile values and principles, enough to become able to recognize in everyday real situation whether an action/decision/practice in that specific context adhere to Agile values and principles and whether not and what are the practical consequences
  
  
• the internals of Scrum and XP practices, know and understand exactly what effects each practice is expected to produce in combination with the others, enough to recognize when a team is already achieving all the outcomes expected from a practice and so the team does not need to enforce that practice explicitly anymore (e.g. as Kent Beck describes in Software G forces), and enough to understand how a modification to a practice could affect the  overall productivity quality and chances of success (e.g. becoming able to adapt/modify Scrum effectively as Jeff Sutherland and Ken Schwaber would do and not the way they wouldn't do)
  
  
• social complexity and self-organisation enough to be able to distinguish between simple complicated and complex problems, make sense of complex contexts, have the tools to identify and explore the unknowns, deal with inherent uncertainty, inspect and adapt to react properly to unpredictable events, to make proper use of available levers to direct and influence the emergence of behaviors toward positive directions to the advantage of the organization the team and to the project success, to amplify the emergence of beneficial behaviors and to reduce or revert the non beneficial ones
  

And you, how would you answer to this challenge?



[1] http://www.ambysoft.com/surveys/success2011.html
[2] http://10yearsagile.org/
[3] http://drdobbs.com/architecture-and-design/229301128
[4] http://scrum.jeffsutherland.com/2011/11/agile-manifesto-10-year-reunion-full.html
[5] http://msdn.microsoft.com/en-us/library/hh350860.aspx
[6] http://blogs.ugidotnet.org/luKa/archive/0001/01/01/abide-model-an-exercise-diversitydissent.aspx

La app web che comprime i tweet piu lunghi in 140 caratteri, é rilasciata e accessible online qui: http://www.luca.minudel.it/tweeeeeeeeeet/

La lista delle abbreviazioni é migliorabile, si possono aggiungere abbreviazioni piu chiare, abbreviazioni che mancano e cambiare l'ordine cambiando cosi la prioritá con cui vengono applicate


Per migliorare le abbreviazioni in Italiano, clicca su
  Switch to Italian Tweets   e poi clicca il bottone
   Advanced View >>>

Save e Load permettono di salvare i miglioramenti e ricaricarli in seguito, e inviano una copia dei miglioramenti al Server cosi potranno essere inclusi nei rilasci futuri della applicazione !

Questa é una delle domande rivolte da Andrea Gervasini per la sua tesi sull'Extreme Programming come conclusione della sua laurea presso l'Università dell'Insubria di Varese.
Trascrivo qui la risponsta che mi sono dato. Commenti e visioni alternative sono ben accolte :)


Cos'é per te XP, la personale visione di cos'è xp tralasciando i libri ?

• Riconoscere in ogni progetto e sviluppo software quello che sappiamo e anche quello che non conosciamo, non possiamo prevedere e non possiamo controllare. e adattare il nostro modo di lavorare di conseguenza. reagendo, adattandoci, esplorando, trovando l'equilibrio tra cio che possiamo anticipare e cio a cui dobbiamo reagire
  
  
• Comprendere il ruolo fondamentale delle persone, immaginare e applicare modi di lavorare che non limitano la capacitá di collaborazione le motivazioni intrinseche e l'intelligenza collettiva che ci sono nelle abilita umane innate e in quelle acquisite da adulti maturi
  
  
• Accettare il paradosso che le attivitá, le pratiche e i compiti piu difficili in assoluto diventano piu sempli di molto applicandoli in modo incrementale e continuo e che risultati e grandi cambiamenti a livello macroscopico si raggiungono meglio (a volte solo) lasciandoli emergere come risultato di un continuo lavoro a livello microscopico
  
  
• Comprendere la complessitá intrinseca di alcuni problemi e come vanno affrontati questa classe di problemi e saper riconoscere nella pratica e nel lavoro quotidiano quali dei problemi che incontro hanno questa caratteristica di complessitá

One of the Learn Ruby Koans exercise is about implementing a method that calculate the score of the Greed dice game.



A friend reviewed my solution pointing out some conditional expressions that could be avoided (from 3 they are zero now), some state that could be removed (greed_roll_scores is calculated and never changed now), and in the way of the refactoring some duplication (2 similar rules of the games now are both applied with a unique common logic) become evident and I removed it.

Here is the resulting score method, I left also the comments with the Greed game description and the original tests:
- http://pastie.org/3146621


How good is this solution?
Again my friend suggested to see how easy is to read (you judge this then) and how easy is to extend with new features.
Well a good design, is emergent, is not required to and do not predict/anticipate future features (YAGNI).
Instead when a new rule is similar to the existing ones, it should be easier/faster then before to implement.
And when a new rule is completely different, well here is where you cannot and should not even try to predict and anticipate; the more you can add new unpredictable rules just adding/extending code and without throwing away the existing code, the more the design is good.


Here there are new rules that I didn't know when I implemented the code in the first place. I can try to add to the initial implementation of the score method:
- http://en.wikipedia.org/wiki/Greed_(dice_game)


The first 4 new rules (4-of-a-kind, 5-of-a-kind and 6-of-a-kind) are similar to the existing rules (3-of-a-kind), let see how easy is to extend the implementation:
- http://pastie.org/3146856
Quite well: only a small change of the existing score method implementation is needed.

The last 2 new rules (a straight and three couples) are quite different to the existing rules, let see how easy is to extend the implementation:
- http://pastie.org/3146991
Quite well: only a small addition of the previous score method implementation. No evidence from here that the design is bad.





Happy to hear your comments and see others solutions




Update: a reflection suggested by Riccardo while discussing off-line is about splitting the logic of each rule in a separate method and having the score method that apply the set of rules. This way make it easier to add a new rule: just define the new rule in a method and add it to the rules collection in score method.
This is the result: http://pastie.org/3151265

Update: a new version inspired by Matteo solution https://gist.github.com/1617603
and here the related unit tests https://gist.github.com/1725633