Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
Beginning a New Book
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
Increase the value of your stand-ups with different questions.
I’ve recently started working with some teams who have elected to use the classic three questions during their stand-ups - “What did you do yesterday?”, “What will you do today?”, and “Are there any impediments in your way?”
I’ve been talking about and advocating for different stand-up formats for quite some time. I, frankly, think the three questions are too focused on individual activity and lack focus on group progress.
If you like the format of three questions, may I suggest you try some different questions?
Agile is "the best"!
I was asked to answer the Quora question, “Why is the Agile model the best”.
I’m not comfortable with the notion of “best”. Maybe “better”, “leading”, or “fit for purpose”. But most of this is so contextual and ephemeral, I tend to avoid the label “best”. That nit-pick aside…
Agility focuses on working in teams together with the customer to deliver high-quality working software in rapid cycles.
Deadlines and Agility
I was recently asked to engage in a debate over whether or not there are deadlines in agile. There were a few folks involved in the debate and the predominant perspective seemed to be that true agile efforts have no external deadlines - all deadlines are self-imposed by the team in the form of an iteration commitment or a scope negotiation with the Product Owner.
This is bunk.
Shippable Stories
Telling the complete story
Lost in Translation - An Agile Game
Esther Derby asks: Are we aiming too low?
Esther Derby put together a nice post on the importance of design for a web site in which she asks, "Are we aiming too low?"
Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?
Roshambo Estimating
This is a quick post. I just want to share a technique we've been using for initial story estimating. I first used this technique at ThoughtWorks when we were working on a project that required a lot of estimating. I think it came about because 1) we did not have any estimating cards immediately available and 2) that is the kind of place ThoughtWorks is. I later came to discover that the technique is not only fun, but it actually has a few additional benefits.
Value is more than money
Michael Nygard tweeted
'The phrase "business value" seems to hide uncertainty behind vagueness. Can we just say "money" instead?'
I disagree. Or more accurately, I disagree with what I infer Michael means by this single tweet. I cannot say with any certainty what he meant, much less address the context of or inspiration behind his statement.
Stories are about why; not what or how
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.