According to xUnit Test Patterns:

The Ruby-based RSPec kicked off the reframing of TDD to EDD (example-driven development), and the Java-based JBehave followed shortly afterword.

– xUnit Test Patterns pg 33

Actually JBehave predated RSpec by a few years. I remember going to a talk by Dan North of Thoughtworks on JBehave in March of 2005. He presented with examples of JBehave and explained how it got people away from thinking about tests. The very next year at SD West 2006 I attended a half day tutorial by Dave Astels on RSpec. It was still pretty early for RSpec at that point about 0.5, but it was already pretty nice because Ruby is just a lot easier than java for writing a behavior driven DSL.

A bit of poking around reveals JBehave actually dates back to 2003 when Dan North started working on it in at Thoughtworks. I think the issues with making nice DSLs in Java probably led to the much larger success of RSpec in the Ruby community and led to the thinking that JBehave came after.

A good PM should annoy a developer some of the time.

It’s like Java Posse for Rails Developers only shorter, funnier, and tightly scripted.

The Rails Envy guys, Gregg and Jason, have put together a great podcast on current Rails news, packed it into 10 minute episodes and spiced it up with humor. You probably already know them from their parodies of the Mac PC ads with Rails versus Java, .NET, Coldfusion, etc. If you haven’t added the podcast to your feed and you keep any track of the Rails community it’s worth adding to your weekly podcast menu.

A core part of Scrum and many other Agile methodologies is ‘inspect and adapt.’ Retrospectives are a key practice in reviewing the last iteration. You toss up on stickies or a white board the ‘What Went Well’ and ‘What To Look Into.’

Diana Larsen held a session at the end of Agile Open California on retrospectives and suggested two key ideas on how to take action after a retrospective:

• Pick one or at most two things on the list to work on for the next iteration.
• Only pick something that at least one person in the room has the energy to take on. If no one has the energy for the next iteration don’t try to force change.

A sign of team self-management success is when the Scrum Master is out or busy and someone just fills in. I’ve known one of our Scrum projects was moving along pretty well, but our organization still has a tendency to try to have another PM fill in at the daily standup. In the old command and control phase this made sense, but with a self-managing team it just becomes a minor impediment. Today I left a Scrum meeting with a big smile as one of the business analysts on the team had facilitated the standup.

Next step is having a rotating facilitator instead of always looking for the Scrum Master to lead.