I've been on numerous Agile projects with varying methods for capturing stories. Quite popular (and purportedly the ThoughtWorks standard) is the "As a, I want, So that" story format.
While I have seen teams do well with this format, I think it can be radically improved with a minor change. I prefer to see "So that, as a, I want" story format.
My reasoning is quite simple; the emphasis is incorrect in the common story format.
Harmonic Mean is a Bitch
A chain is no stronger than its weakest link. Metaphorically, this applies to teams. But in actuality, this is simply not the case. Humans have not only tenacity, but the ability to countervail one another. This is a quality that inanimate objects simply do not possess. We can and will compensate for one another for the good of the team. Links in a chain are incapable of sharing their strength. No other link can compensate for the weakest.
Caution: Metrics change behavior
Measuring and reporting are important
I've often heard said, "That which you cannot measure, you cannot improve." And while I do believe this is a general truth, I think it fails to tell the entire story. It is not just about what we can measure, but what we actually do measure that is significant; "That which is reported, will improve."
Introduction To Functional Programming with Scheme
What if no one reads it?
Among the books I am currently making my way through is "Exploring Computer Science with Scheme" by Oliver Grillmeyer. The publish date on this particular book is 1998. No matter how often it happens, I feel a twinge of despair for our profession when I read sound advice from a decade or more ago that has yet to be widely adopted; or worse is still hotly contested.
Grillmeyer contrasts a couple different functions that accomplish the same end. One terse, but obfuscated; One verbose, but transparent. In conclusion, Grillmeyer states, "In a tradeoff between readability and length of code, you should favor readability."
Business Value is not the only reason to adopt Agile
Agile Rob posted a column a few days ago entitled, "If You Don’t Focus on Business Value, Don’t Adopt Agile." He tweeted it out and after reading it, I replied that I did not entirely agree. Rob asked that I post a comment on his blog. The following is an extended/modified version of that reply.
I read two articles today, "Adopting Agile Isn't The Point", by Mike Cottmeyer and "If You Don’t Focus on Business Value, Don’t Adopt Agile.", by Robert Dempsey. Rob's posting is an expression of agreement with Mike's.
Martin Fowler on Technical Debt
Martin Fowler just posted an article on Technical Debt in which he discusses the Technical Debt Metaphor. Fowler argues that the metaphor should (and does) include messy code. He talks about deliberate and inadvertent debt as well as reckless and prudent debt. Prudent and Deliberate is the most desirable. While Reckless and Inadvertent is the least desirable. He published the following quadrant to help explain his concept.
Craftsmanship
I have the profound and intimidating honor of being the fifth person to make note in the Wandering Book. To be honest, I'd hoped to be later in line. I'd hoped I could read numerous entries and ponder all the wisdom before it came my turn to write. As the fifth, I have to admit there is already a great deal of wisdom in the book. The four before me are remarkable people. And those who will follow me are surely remarkable as well.
I'd rather be in last place
I joined the cross country team my freshman year of high school. I knew nothing about the team and little about the sport, but I figured running wasn't too difficult and was certainly less dangerous than football.
It turns out the team was one of the best in the state. They had a legacy of excellence for well over a decade. They consistently won their league, placed in districts and regionals and sent at least individuals, if not the entire team to state.
Messy Code is not Technical Debt
Technical Debt is a common topic these days. How is it incurred? How should we track it? When should we pay it down?
It is a metaphor commonly understood. Our customers get it. While they may not like it, they do understand. Technical Debt is incurred today and needs to be paid down; preferably sooner rather than later what with compound interest and all that.
Create a Culture of Integrity
My friend Patrick Wilson-Welsh once asked me if I knew the key distinction between Accountability and Integrity. I said I did, but then found myself struggling for an answer.
Today, I think I get it. Perhaps I should check with Patrick.
Keep Retrospectives Fresh
Retrospectives are an important (and frequently poorly done) practice. They provide an opportunity for discussion, learning, and adaptation. Without retrospectives, a team is likely to fall into a soothing rhythm and fail to recognize early the need for change.
But retrospectives themselves can become common and numbing. The same moderator, the same three questions, in the same room, at the same time .... (yawn).
Here are a few tips on keeping your retrospectives fresh.