Retrospectives are my favorite of all the scrum activities because they represent the opportunity to reflect on how we are implementing and to adjust our behavior to be more effective.
I have said to my teams on many occasions that if I were forced to choose only one scrum ceremony that my choice, without hesitation or reservation, would be the retrospective. Without it, how could we ever expect to improve? What essential difference would an “Agile” project have over the many death march projects that teams have come to accept?
I have often argued that the founders of Agile did not provide reasons why their approaches worked just that they did. Their was empirical evidence, proven by doing the work, or, as they state in the beginning of the manifesto – uncovering better ways of developing software by doing it and helping others do it. From their very pragmatic approach, they figured out that better software was created by following the values and principles. One of those discoveries was that better software was created by self-organizing teams.
In 2002, Jim Johnson of the Standish Group (made famous by their Chaos Report of software project “success”) presented findings of features and functions used in a typical system. The number of features that were never or rarely used totaled a whopping 64% while sometimes, often and always weighed in with 16%, 13% and 7% respectively. For those acquainted with the Pareto principle (80/20 rule), notice how the often and always used features – those things we should concentrate on building for our customers and those things things that bring us the most value – is exactly 80%.
In other words, a great deal of our effort is generally spent creating things that customers do not use or want.
This principle is much like the one previous about sustainable development. Agile doesn’t ask us to shortcut quality and increase technical debt in an effort to deliver software faster. It is precisely because we do not shortcut quality and incur technical debt that we are able to move faster.
I have worked with many teams to introduce Behavior Driven Development (BDD) because, among a great number of other advantages, BDD allows developers an easier way to access the practice of Test Driven Development (TDD). And, in my experience, TDD is the only way I have seen out of the practice of “Big Up Front Design”.
Metrics. Metrics. Metrics. We love numbers. We measure and put numbers to all kinds of things. We use these numbers to mark our projects as red, yellow and red (of course, the project is always green until there are a few weeks left when someone finally blinks and acknowledges reality and begins to use yellow or, god forbid, red).
Unfortunately, in our headlong rush to create metrics we tend to forget the why of what we are doing. Numbers and statuses become an end unto themselves.