At Qualogy, where I work, we have a team that acts as a recruitment agency for freelancers towards our customers, so that we can help our customers fill open positions even when we don’t have a suitable internal candidate. This team’s main goal is to find suitable candidates as quickly as possible, offer them to the customer, and help both to come to a mutually acceptable agreement. The team of three that takes care of this work was looking for ways to improve the service to their customers.

I’ve been following some of the discussions on the differences between Scrum and Kanban. And learning more about Kanban, of course. One point that is emphasized a lot is that Kanban requires fewer up-front changes than Scrum does. The term “Big Change Up-Front”; has even been coined, by Alan Shalloway. There’s certainly truth in that. Scrum doesn’t have many rules, but it is very strict in assigning a very limited set of roles and responsibilities.

Peter Stevens, over at <p style="display: inline !important;"> <p> </p> <p style="display: inline !important;"> I like Mary's response a lot, where she basically states that Scrum and Kanban each have their own strengths, and each is suited for their own specific set of circumstances. </p> <p> </p> <blockquote> <p style="font-family: 'Times New Roman'; line-height: normal; font-size: medium;"> Scrum is basically a method of accomplishing work through cadenced iterations. Kanban is a method of accomplishing work through limiting work-in-process and managing flow.

An old article I just came across, posits that learning is the thing of value in software development: When we present this hypothetical situation to students – many of them with 20+ years experience in building software – they typically respond with anywhere between 20% to 70% of the original time. That is, rebuilding a system that originally takes one year to build takes only 2.5 to 8.5 months to build.

While looking for ways to make using Selenium nicer, wondering a bit through WebDriver descriptions and FitNesse explanations, I ran into this nice Introduction to Behaviour Driven Development. Dan North explains how he arrived at the ideas of BDD, originating with a desire to explain how to best do Test Driven Development in his teams, and arriving at this structured way of creating the tests that drive implementation. Very illuminating, and worth reading if you take your testing seriously.

Reading the Scrum Development mailing list is always a good for some inspiration. Today there was some discussion on how to split user stories. These are meant to be sent out to prime mail boxes of registered memebers. Although paper mail has begun phasing out, we would like to keep it going. Next to some good examples in the mailthread, Charles Bradley also provided a link to Patterns for Splitting User Stories by Richard Lawrence.