Forbes has a good article on The 10 Questions You Should Never Stop Asking . http://www.forbes.com/2009/11/20/ten-key-questions-entrepreneurs-management-k...

* What is our purpose for existing?

* Who is our target customer?

* Why does anyone need what we're selling?

* If there is a need, is it enough to support a profitable business?

Seems like basic stuff, but a good reality check.

Phenomenal parking prices around the world as shown in a recent article in The Economist (http://www.economist.com/daily/chartgallery/displaystory.cfm?story_id=1402944...)

I was amazed at the car parking rates being charged in London when I was there a few months ago.

Are you also paying too much for parking?

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

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.