A “catch 22” for those that don’t know is a term that came from the famous book about WW2 bomber pilots who were forever caught up in an impossible position. It can be distilled down into the simple choice between stating you are insane and thus no longer fit for duty and being denied being declared insane because only a sane person would like to stop flying in the bombing raids.
My favorite part of the book is the end result of a world filled with “Catch 22”’s. Where wanting to progress in this world forces people to plan and execute very successful bombing raids on their own airfield and base. A result clearly not intended by any of the people involved in the creation of the parts that make up the “Catch 22”’s.
“Catch 22”’s are clearly a great reason to always value individuals and interactions over processes and tools. Because they get their strength and are created by those processes and in most places they override both the people they are there to serve and the people who created them. So it’s pointless getting frustrated by the people who create them because they most likely value processes more than you do and more likely more deeply caught up.
How do you learn?
As a member of a scrum team, it’s an important question. How does the team learn? I mean we spend a significant amount of time in retrospectives for the purpose of learning and improving.
For me as an individual, I need to do something before I really understand it. I learn by doing. I learn about agile by delivering working software as a member of a cross-functional team. Is there another way of learning about Agile without doing it in practice?
Our fail wall has failed because it was taken down for saying a fail wall. This is only a reasonable reason in an earthquake zone after a major earthquake. So what was learned? Timing and wording are important when putting up a fail wall.
Went to the second code kata focused on Test Driven Development at Adscale. Code katas is a very Agile thing to me. The more exposed I become the more I prefer it to normal sessions and discussions.
The katas are:
Focused on working software.
Face to face.
To learn with using close collaboration.
The focused on doing.
Fail fast and learn from it.
Set for continually improving.
Definitely going to the next one.
Antoine de Saint Exupery wrote: As for the future, your task is not to see it, but to enable it.
This talk has a nice explanation of the fragility of large IT projects and large top-down organizations.
Ended the year with a good, relaxed retrospective. In the last sprint we over delivered on the last day. Which set a great tone for the retrospective and the end of the year break.
But I also did a simple retrospective for my year. It set me up for a relaxed year of end break. It also helped me set some goals for next year.
Try it if you have time.