Skip to main content


Showing posts from April, 2013

Automated Agile Testing Is Needed, And Someone Needs To Decide To Do It

Did you wake up this morning and think to yourself, "gee, I think I'd like to try some agile today?"  Allow me to leap between you and your coffee to announce that your adoption of agile requires more than just management techniques (stand ups, burn downs, and card walls).  You are going to need a framework for running automated tests on a scheduled and ad-hoc basis, and some well-engineered tests within that framework, if you are hoping to get your company's software faster, better, and more transparently for more than a couple of weeks.

What, you say?  Yes!  You must act now to avoid the following:
Bad Quality.  For starters:  How were you planning to know if your software is okay after the first two weeks?  I'm already worried for you, if your plan is to follow a book of some kind and simply have "a product owner" do some "inspection" and say "tally ho."  Gradual Slow Down.  But worse, let's say that works and your new web…

Fixed Bid Agile Without Cognitive Dissonance

I've been following a LinkedIn forum discussion with interest entitled "Could we use Agile methodology with a fixed bid contract."  There are some quick, snappy answers to the question which came up immediately which I will quickly put into two categories:
Straightforward:  NEVER NEVER NEVER.  Run away!  Screaming!  These people don't understand agile.  It's a smell.  It's a TRAP!   I'm embarrassed for you.Nuanced:  If you must do this, here's how to make the best of a bad situation (offers advice with implied background nose holding). Of course, there were also some really useful answers, pointing to blogs like this really nice one from codesqueeze, recommending "target scope" or "target cost" models rather than either "fixed bid" or "time and materials."

Let's talk about "fixed" things though.

I'm always intrigued by people who think a perfect stranger should hire them to build software on a &…