Henrik on Scrum Vs Kanban

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"

RSpec, Authlogic, Factory_girl - TDD goodness

Whilst trying out Authlogic for a new project, I realized I was scooting ahead with a lot of *gasp* untested code. What would Kent Beck say? A quick google search somewhere along the lines of "rails rspec authlogic OMGWTFBBQ" netted this great tutorial from Mathieu. I didnt bother with the resource_controller, but I can confirm the thoughtbot-factory_girl / authlogic / rspec / rspec-rails combo works nicely.

Defragment your day

The folks over at New Leaders posted a very interesting article about how they divide their day, which basically entails;

  * 9am -12am - Heads down, get sh*t done, no distractions no email.

  * 12-1 - Chow down

  * 2-6 - Admin/Meetings

  * 6-10 - Personal time - clock off - go pet your lizard.

  * 10-1am - [optional] log-on and remotely get shi*t done.

Media_httpimgskitchcom200905068hfc21uu933nhqtwwd12n6ha26previewjpg_akzfcicvaubjceq

Uploaded with plasq's Skitch!

10 Reasons why PHP is Still Better than Ruby ;-)

This post brought a smile to my face. Unless you're workin on a project of your own, producing as little and maintainable code as possible will mainly DRY up your paycheck. You spend less hours copying and pasting, less hours fixing the same bug on ten different lines and less time finding bugs in the first place. But remember: Time equals cash when you're contracted by the hour. So we should be grateful for PHP and frameworks like Zend which make it so ridiculously easy to write the most cumbersome code full of duplications.

Agile approach => Agile RFP => Agile Vendor

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?"