Ephox adopted eXtreme Programming (XP) at the beginning of 2006 when Doug joined the team. As part of our commitment to continuous improvement we have XP Adoption Reviews every few months. The aim of these is to review the XP practices with a view to rating our success with adoption of them. From this we choose 3 to focus on for the next few months.
In our first review, we identified Test Driven Development (TDD), Daily Stand-ups and Iteration Demos as the practices we would get the most value by focussing on.
I was reading an article by Jean Tabaka on the 11 Ways Agile Adoptions Fail and her number 5 reason "Product Owner is Consistently Unavailable" hit a cord. In it she states
An unavailable product owner perpetuates the wait time and creates waste
Having experienced this in the past, I can't agree more.
You will often hear the terms "People Independence" or "Institutional Memory" used as a management reason for the creation of the huge volumes of paperwork often created in a BDUF (Big Design Up Front) project. The idea of course is that the presence of the documentation allows the organisation to use developers interchangeably.
For developers, documentation is extremely useful for the those who come after, even if it's you in 12 months time. This documentation however is only useful if it's up-to-date. Unfortunately in most cases it's written, read and never looked at again.
I was recently reading a post on InfoQ, "Frequent Retrospectives Accelerate Learning and Improvement". As it's title suggests, the key messages in the article is about having frequent retrospectives to aid in the learning and improvement process.
When we adopted XP (eXtreme Programming) we undertook to have a retrospective at the beginning of each development iteration, preceding the planning game. With weekly iterations, we have a chance to reflect on the previous weeks pluses and to formulate some changes/improvements (deltas) identified from the week.
While writing a post about retrospectives and deltas, in response to an article by Deborah Hartmann on InfoQ (Frequent Retrospectives Accelerate Learning and Improvement), I noticed a disturbing comment mentioning the "traditional blame party".
Deborah's post referred to and quoted from an article by Rachael Davis entitled "How To: Live and Learn with Retrospectives". The quote from Rachael's article included the following sentence.
Without these in place, conversations are likely to be full of criticism and attributing blame