Pragmatic Agilist

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. http://www.fanpop.com/clubs/coffee/images/25055460/title/love-coffee-wallpaper 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 "t

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 t his really nice one from codesqueeze , recommending "target scope" or "target cost" models rather than either "fixed bid" or "time and materials." from http://www.cytrion.com/businessmodel Let's talk about "fixed" things though.   I'm always intrigued by people who