Skeptek.com

Life at an Internet Startup by Keith Forsythe

Don’t Mix Brainstorming and Estimating Effort in the same Design Meeting

Recently, Derrek Long, my system architect, asked me to read a few pages from the book I.M. Wright’s Hard Code by Eric Brechner.  He had observed issues our company was having with mixing brainstorming and scope cutting in the same meeting.  Brechner describes over a few page in Chapter 5 how to avoid getting FOCKED, or “Failing to Orchestrate Collective Knowledge Effictively for Design”.   Essentially, Brechnar preaches to have very specific goals for a meeting, and to avoid at all costs mixing goals, especially when the goals are completely opposite to each other. 

After reading Brechner, and thinking about it for the last few weeks, I’ve expanded this idea out a bit further as to why mixing brainstorming and estimating effort during initial design meetings between the business stakeholders and development is a bad idea.

  1. Discussing effort for each idea discourages creativity when brainstorming.  People will be less likely to offer “out of the box” or “half baked ideas” that need to be flushed out if they are afraid they will be scolded for coming up with something “too hard”. 
  2. Dev often will give a big estimate when they don’t like an idea.  So waiting to estimate the idea at a later time demonstrates that dev still put in the due dillagence to consider the idea and the estimate isn’t just based on dev not immediately liking it.
  3. Initial estimates given 10 seconds after hearing an idea in a brainstorming meeting will be less accurate.  Dev needs time to absorb the idea, think it through, and then offer an estimate of effort.  Even spending 5 or 10 minutes considering an idea results in the developer spending 100 times more time considering the idea and will result in a more accurate and reliable estimate. 
  4. Other ideas presented later in the meeting might add further clarity to earlier ideas or might prevent the idea from needing estimation altogether. 

I would love to hear from other people their experience with keeping brainstorming and estimating separate.  If you have techniques you employ to do this, let us know!

May 1, 2009 Posted by Keith Forsythe | Development Management, Project Management | | No Comments Yet

Tips for Hiring QA Engineers for an Internet Startup

The one position I continue to have trouble hiring for is QA.  I manage a development team of 8 others.  5 Ruby on Rails developers, 2 Java and C# developers, and a system administrator.  My team is quite sharp.  Finding a QA person that can fit in to a Internet Startup Agile Development team has been quite a challenge.  And if you are a small company, like mine, you only get one person for this role.  The person you hire needs to be a rockstar.  No budget to have multiple people.

So what makes a great QA person?  Well I believe you should look for the following qualifications:

  • QA Vocabulary.  Nothing is more annoying than a QA candidate who can’t tell me the difference between white box and black box testing.  There is a good set of software QA terms here http://geekswithblogs.net/srkprasad/archive/2004/06/02/5795.aspx and here http://www.aptest.com/glossary.html
  • QA testing skills.  I usually take a story that is ready for testing and have the candidate take a shot during the interview.  I find it useful to leave the candidate alone while they do this. 
  • Resumes that have grammer/spelling errors… trash ‘em.
  • Extension of the product manager.  I don’t get to review every story that is developed and release, but the QA engineer does.  So your QA person is an extension of your product people/person.  It is critical the QA person get a feeling for what your product manager likes and dislikes. 
  • Hard Ass.  You need to make sure that your QA candidate can stand up to manipulative developers that try to convince the QA person to “it’s not a bug, it’s a feature”.  The QA person needs to not roll over everytime they are steamrolled.
  • Flexible schedule.  That’s right, the QA candidate needs to be comfortable with working long days and nights, especially just prior to a release. 
  • Relevant experience.  Hiring a QA person for web testing that only has tested windows clients is not a good idea.  You are a startup, you need results fast.  Your not in training mode.

And of course, finding this person sure isn’t easy… so good luck!

December 14, 2008 Posted by Keith Forsythe | Development Management | , , , , , , , | No Comments Yet