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. That meant being quicker to offer possible candidates to customers, but also to provide faster feedback towards (rejected) candidates.

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. Kanban can be used with existing roles, as long as you make make sure you make the existing roles and policies explicit. Asking which one of those option is better is really beside the point. It simply depends on the context. In my situation, I usually get called in by companies who have already decided to ‘go Agile’, and as such are already part way through some of those changes. Of course, the changes are not always successful, but it doesn’t provide me with a change to start slowly.

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. I have found that some work especially creative work is more effectively managed with iterations, while other work especially naturally sequential work is more naturally managed with Kanban. &#8212; Mary Poppendieck
        </p>
      </blockquote>
      
      <p style="font-family: 'Times New Roman'; line-height: normal; font-size: medium;">
        She also stresses that, whether you choose to use Scrum or Kanban, the point is that you keep improving on your way of working, so:
      </p>
      
      <blockquote>
        <p style="font-family: 'Times New Roman'; line-height: normal; font-size: medium;">
          Lean would have every company view these techniques as starting points that are constantly improved, so after a few years, Scrum and Kanban should evolve and change to something quite different than their starting point. &#8212; Mary Poppendieck
        </p>
      </blockquote>
      
      <p>
        This suits the way that I view these things very well. Use the tools most suited for the situation, and see where it leads you.
      </p>
      
      <p>
        Of course, the best way to choose is to try each, and measure results. Which brings us to another question: what and how do we measure? At the moment, I'm leaning towards flow (time for work to flow through the system), and Henrik Kniberg's <a href="http://blog.crisp.se/henrikkniberg/2010/05/08/1273272420000.html">Happiness index</a>. Getting that last one adopted anywhere is going to be an interesting challenge, though...
      </p>

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.  That’s a huge difference!  It’s hard to identify another single factor that could affect software development that much!

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.