Thursday, November 27, 2008

Take your system for a SWiM

Marcus Ahnve voiced some intresting thoughts about 'should' and BDD in his post "Words dont come easy: MoSCov and BDD". Here's a few follow-up thoughts.

Since we write tests mainly for two reasons, to validate that we built something right, and often even more important, that we built the right thing. We often seek answers along the lines of, how does this class or compononent work? How do I use it? What precondition must be fullfilled? In short, we want answers.

I propse we learn our tests to SWiM!

S(hould)

The SUT should do something, the core of BDD. "The index page SHOULD have the title...". Great for starting conversations, discussion friendly since it's a quite soft expression that's easy to question with a simple "should it really?".

W(on't)

The SUT simply shouldn't do this. "Reading the same item twice WON'T cause multiple database calls." Good for thoose "Should not" moments.

i(nstruct)

How do I use this component? Learning tests, code samples and the like qualify. Capturing small scenarios as tests can be a nice way to spread knowledge on how to use the SUT, show best practice's and document often raised questions.

M(ust)

The SUT must always do this, "Authentication MUST fail if given the wrong username and password".

As Marcus points out in his comments "BDD is all about conversation" good conversations need strong and shared vocabularies.

Monday, November 17, 2008

Scrum ate my baby!

Parts of the agile blogosphere is ablaze with a heated debate on the topic if Agile is failing, and if it is, shoulde we all just blame Scrum?

James Shore posted "The Deciline and Fall of Agile" not really denouncing Scrum, others have been pointing at it for some time now, and Robert C(raft manship over Crap) Martin has replied to much of the debacle with the witty "Dirty Rotten Scrumdrels" putting blame where it belongs right smack in our own laps.

Someone left a comment with "Scrum is the VB of Agile" a utterance that actually deserves some exploration.

What they share is that they took something complex, hard and arcane, creating rich UI applciations and Agile respectivly. And made it approacable for the so called unwashed masses. I've seen people without programming experience build their first usefull applications mere hours after installing VB, and I've seen well meaning people skim a Scrum brouschure and then going of to lead an Agile, no SCRUM! transition. Neither turned out maintenable or sustainable in the long run.

Strange that.

Where they differ is that VB was basicly from the ground up designed for novice users in mind, Scrum on the other hand can argubly be called an expert system. Scrum is most often presented like "Do things that work!", if you got a bit longer attention span it's more like "Do more of what works, and STOP doing stupid stuff we know doesn't work." for thoose really instrested a catalouge of simple (as Chess and Othello) princiles are given that have proven their worth for a good bit over 20years. Scrum doesn't tell you to eat brakefast (a generally good advice nontheless) and it doesn't have a prescription on how to figure out what to really build, it simply states in essence that the Prouct Owner is resoponsible for the viability, marketabillity and vision of the product.

Now, that's a hard problem by any means and it's given about two sentences in the offical Scrum litterature, you're supposed to look at your situation, your experience and the countless tomes written on Use Cases, User Stories, segmentation etc to achive the goal of actually knowin' where you're goin'.

Scrum tells you to deliver working, shippable software every iteration. It doesn't tell you how to actually achive that, and that's the beauty of it. It's also what makes it insanly hard and why people are basicly setting them selves up for disaster when proclaming "We'll do Scrum and all our problems will vanish!". Thus, uncle Bob is right, we can't blame Scrum, it's like trying to blame the sane albeit open advice of "Do what works!".

The problem with Scrum and much of how it's marketed is that in relation to the Shu-Ha-Ri model it is most often communicated on a "Ri" or fluent level it's a framework built on philosophy and basicly that's why there's such intense discussion and so many pleas for help in the practical things. That's also what makes "Scrum and XP from the Trenches" such a valuable book for many, it's author calls it "Sample code for doing Scrum and XP" it's a code sample not the only way, but it's often cited as a definitive refrence on the one way to do things. Simply because it's the most readable and readily available book with both concrete advice and Scrum in it's name. Other methodologies like Kent Becks XP and Alastair Cockburns Crystal family does communicate in a broader way catering to both beginners needing practices and procedures and giving experienced users the needed background to understand why they work.

The community and our proffession needs to grow up, there's no easy way to greatness, there's no silver bullet, and nothing substitues hard work and understanding. I look forward to seeing this unfold, perhaps it will for a moment reverse the current trend of trying to earn badges for being agile and start the road to understanding why agility works and apprication for the large body of knowledge present on how to successfully deliver projects that please their stakeholders, sponsors and users alike.