(luKa)

Looking at the successful artists I see that most of them spent their whole life learning and developing their techniques and languages, experimenting and practising, all before been able to create their masterpiece they are remembered for.


We computer programmers use to proclaim ourself senior on some technique/technology after few years of practice. And for some of us the next step is to start to teach others and stop learning, questioning our assumptions, and so stop improving. The same is true when we developers learn, practice and master Agile, trying also to become Agile ourself.


We usually learn the new language of Agile, the new prospectives and the related soft skills. We learn to use board, post-its, informal meetings, be empowered, work together. We begin to learn and master the coding and team practices, we face the first difficulties and failures, we get involved in the community, we read listen learn and try things out, we learn from our mistakes and we get our first successes and victories. And we get able to repeat those successes again.

And here it comes! Some (many?) of us stop to feels as beginner and proclaim themselves senior, start to teach to others and stop learning and challenging themselves out of the comfort zone. We start to walk with the truth in our pocket and fiercely debate with others self proclaimed seniors about what is the right way, what is the best way, and what is the wrong one (is this that wicked problems teaches us?).

And then some of us sign the Oath of Non-Allegiance manifest, to make it clear to others that when there is a debate about what's the best way, they are the open minded one, the one that listen and try to understand others opinions, is the other guy that not us that is evil, that do not listen, that do not understand that he is wrong while we are right (that wasn't the intention of that manifest, isn't it?).

And some of us also claim themselves to be Beyond Agile to make it clear to any other self proclaimed Agile expert that they are one step beyond, I mean they do not even need to learn and understand more about Agile indeed they are beyond Agile, that's why in case of debate, they are the one who know what is the best/right way and the others are wrong, behind (was about this cooperation and collective intelligence?).



Sound familiar?



Once my Judo master after mentioning the guys in our dojo that reached the black belt asked us if we know what was the difference between them and the others.
After listening to us he pointed out that those guys did not gave up with Judo they continued to practice and improve until they reached the black belt grade and they are still practising to improve, while the others gave up so they did not reached the black belt.
Few years later I gave up Judo to start with Rugby, and then I gave up also with Rugby to work and study computer science. You can bet, I've never become a Judo's black belt and I never played in a first series Rugby match.





I also know by myself pretty well that after every success, the next success is often much harder to reach and there are less people that can tell us where to start and how to proceed with that.That's why moving from Beyond Agile to Advanced Agile can be scary and require a good dose of humbleness, courage and confidence. All skills that we have already developed in our Agile journey till today. So yes, we can do it.




Now let's try to imagine where to start our journey toward Advanced Agile.
I come up with 3 ideas. Read them as example and let me know your ideas to learn improve dig into Advanced Agile out of our comfort zone, one more step near the masterpiece:

• Retrospective:
  
  • deepen the understanding of retrospective coherence and use it while looking at facts and finding actions during the retrospective.
  • looks into the Cynefin framework to identify where the obstacle stand (simple, complicate, complex or chaotic quadrant) and how to deal properly with it
    
    
• Design:
  
  • move from avoiding coding horrors, avoiding conditionals/If and removing code duplication to also removing logic duplication and making explicit and exploiting similarities in abstractions at any abstraction level,
  • move from assigning methods and responsibilities to the right class to also grouping properly responsibilities in namespaces, in assembly/binaries and in domain models and when required mapping between different domain models
  • move from a design quality that do not slow down development to also a design quality that boost development x times faster
    
    
• Incremental/iterative development:
  
  • move from iterating when doing maintenance of an existing product  to also an incremental iterative approach also when creating a brand new product, involving financing and marketing and product development.

Do you have more directions to suggest?

Look also: The Beginner’s Mind, Patrick Kua