http://antoine.vernois.net/scrumbut/?page=test&lang=en

I really liked this comparison Henrik makes; "Both are Lean and Agile ... For example

• Scrum and Kanban are both pull scheduling systems, which corresponds to the JIT (Just In Time) inventory management principle of Lean.
• Scrum and Kanban are based on continuous and empirical process optimization, which correponds to the Kaizen principle of Lean.
• Scrum and Kanban emphasize responding to change over following a plan (although Kanban typically allows faster response than Scrum), one of the four values of the agile manifesto.

... and more"

Posted to our Agile Contracts discussion: Peter Stevens talks about an agile approach to building an agile RFP to attract an agile vendor. I found this an interesting read. Peter describes building the RFP in an agile manner, using SCRUM. I've also used SCRUM in this way, in building a full training course, which like Peter's RFP, is just documentation. An interesting application of SCRUM, which I can vouch for (we had good results from this project). Not only does Peter talk about the principles of Agile Contracts, it shows a real-world example RFP structure (albeit with an enlightened customer!). It talks about the downsides (waste) of traditional RFP writing; The process of writing a huge RFP, evaluating and eventually accepting complicated bids from largely unknown vendors is wasteful, risky and expensive. A customer will often invest substantial effort into creating a Request for Proposal (RFP). I've seen RFPs whose size is measured in binders and the effort to produce them measured in man-years. A vendor will often invest comparable effort into winning a big project. On both sides, this effort produces mostly paper. These artifacts have no value except as means to the goal of selecting a vendor. Finally he talks about selecting the right Agile Vendor, with a focus on SCRUM, XP, Agile Estimation, and of course, productivity. He even suggests engaging the top two vendors in a (paid) competitive sprint before the final selection. I've met other customers who've done this and they report fantastic results with their chosen vendor. Skeptics will point out the cost of paying two vendors in a competitive evaluation such as this, but a better question is "what is the cost of *not* doing so?"

"If programmers got paid to remove code from sofware instead of writing new code, software would be a whole lot better." - Nicholas Negroponte Billy Hollis warns of the danger of software addiction;

Object Mentor : "If you are working in an Agile team, don't feel guilty about taking a day or two to think some issues through. Indeed, feel guilty if you don't take a little time to think things through. "

Quality Assurance in software development, is not the sole responsibility any one team, yet the structure (and project schedules) of many organizations makes the Test team, in particular, "accountable".

The net effect is you end up with strange beliefs that "not letting developers talk to testers" will improve the quality of the software product. What gives?

At what point did we lose the plot?

Fortunately, there's some smart folks out there who realize there's a better way. Competitive software companies nowadays are doing some interesting things;

  * Building & Testing what the customer actually wants (BDD, Agile Specs

  * Not wasting time (and money) on stuff that's not important. (MMF, Getting Real)

  * Automating things instead of doing them by hand. (Like testing!)

  * Training people how to write Code That's Easy to Test (the Pragmatic Programmer)

  * Training people how to write tests for that same code (cmon, this is basic QA people! Educate your developers.)

  * Training people to write & run those tests before they write any code (e.g. BDD/TDD/XP )

  * Isolating bugs when they are introduced, not 6 months later (Continuous Integration) And last but not least;

  * Responsibility, accountability and pride your own/team's work. (Leadership, Software Craftmanship, SCRUM)

Easier said than done, yes, but its not rocket surgery.

 

As a developer, you might want to ask yourself why Pair Programming is something you should be bothered doing? "Jeff Langr suggests the following;":http://langrsoft.com/articles/pairing.shtml * Awareness of other parts of the system * Resume building * Decreases time spent in review meetings * Continuous education. As someone who thinks he is a pretty hot programmer, I still learn new things every day from even the most junior programmers. * Provides the ability to move between teams. ("this team is boring," "I can't stand working with him," "that stuff they're doing looks cool."). Since this can be a benefit for management as well, they don't have to clamp down on their resources. * More rapid learning as a new hire. You don't sit and read out-of-date manuals for a week, or worry that you're going to be fired because the system looks indecipherable. If you want some out-of-date manuals to read, I have a couple lying around that I don't use anymore. Me, Im too busy Pair Programming to read em.

Here are some notes based on "Jay Fields article on Pair Programming":http://www.infoq.com/articles/adopting-pair-programming h4. Goals * team enjoys pairing * more productive * team building * efficiency * knowledge sharing * better code quality h4. Methods * 60-95% of core working day * no-one advocates 100% * Only production code written by pairs (XP) h4. Pairing Stations * flat, long desks * 2 ppl comfortably * fast machine * 2 x 24" or 2 x 30" monitors * 2 keyboards & 2 mice * uber chairs * create an environment >= working on own computer h4. Tools * use best-of-breed tools (vi/textmate or whatever) * iterate - find your sweet spot * image for quick deployment * re-image regularly ** encourage dev's to add tools to the image h4. Pair Switching * benefits ** shared expertise (tools/domain/patterns/testing etc) ** balance learning & mentoring * min 1 day * max 2 days * alternatives ** once per iteration ** promiscuous pairing h4. Driving * Ping pong programming * Mentor ** teach Learner to fish * Learner ** take control ** discuss / understand / implement / learn * m,l = l,m ** roles can swap! h4. Anti-Patterns * Uninterested Pair ** not talking. * Distracted Pair ** Helping others ** Checking email ** ancillary tasks * Spellchecking Pair ** Large experience gap ** time pressure ** 1 person reduced to spellchecking ** cannot bridge gap & deliver - split h4. Dont pair when * Some things can be better done on own E.g. ** Research ** Spiking ** Debugging (when large experience gap) ** Doco ** Admin chores h4. Managing * don't force to pair * pair properly, see if they prefer * opposing views ok ** but intra-team they should agree

Grappling with the best way to capture our client's requirements in an expressive (and agile way), we are giving Cucumber a serious consideration. I wont go over the ins & outs of Cucumber, as there are plenty of resources already available. Here's a brief of the steps that I followed (and some of the issues I ran into), which should prove useful if you are doing something similar. h4. Install the Cucumber gem @sudo gem install cucumber@ If you're also having trouble with "gem install" (mirror server timeouts), wget the .gem, and build the gem yourself h4. Getting Cucumber to talk to Selenium Follow the steps in "Aslaks Setup":http://wiki.github.com/aslakhellesoy/cucumber/setting-up-selenium h4. Install Webrat @sudo gem install webrat@ h4. Start the Selenium RC server selenium Cucumber comes with 2 trivial examples, which you can run; h4. Running the sample Cucumber + Selenium test cucumber ../selenium/features/ Ensure this works first before trying the Webrat test below; h4. Running the sample Cucumber + Selenium + Webrat test To run the example test which includes Webrat, you can also use the rakefile supplied; @../examples/selenium_webrat]$ rake features --trace@ Jackpot Winner! or not. For me at least. I hit the wall with a timeout error, which is probably some missing Webrat config; Note: if you are also having trouble with timeouts, at time of writing there was an "unpatched bug":https://webrat.lighthouseapp.com/projects/10503/tickets/205-patch-timeout-parameter-passed-incorrectly-to-selenium in Webrat, which can be fixed by a monkey patch. For me this solved one issue, but the above remained. But I personally prefer the syntactic sugar that Webrat gives me, so its worth getting this working. click_button('btnG') versus @browser.click 'btnG' h4. Other Methods In my quest for Cucumber Glory, I did stumble across these useful, related resources; # "How To Setup RSpec, Cucumber, Webrat, RCov and Autotest on Leopard":http://www.claytonlz.com/index.php/2009/04/how-to-setup-rspec-cucumber-webrat-rcov-and-autotest-on-leopard/ # "Testing Non-Ruby Applications with Cucumber":http://www.vitarara.org/cms/testing_non-ruby_applications_with_cucumber # "Using Cucumber for Acceptance Testing":http://www.pathf.com/blogs/2009/03/using-cucumber-for-acceptance-testing/ # "Cucumber...with webrat mechanized sessions":http://www.pathf.com/blogs/2009/03/using-cucumber-for-acceptance-testing/comment-page-1/#comment-6101 ## And oelmekkis "env.rb":http://gist.github.com/82813 h4. My currently installed Gems FYI my gem versions at time of writing;