How many printers does it take to build your application?

Its a little known fact that Google was built by 3 staplers, a set of  paperclips, and a couple of 2 by 4s.  Yep, some smart dude with a great  idea had someone look at his product and that person replied, ‘We can  do this.  We just need about 4 dev resources and a few QA resources.’

As ridiculous as this sounds, we still see it regularly in software  development.  Not only is it amazingly demeaning to call people  ‘resources,’ it also leads to other fallacies, such as:

  • 100% utilization of each ‘resource’ is ideal – FALSE
    • You can have each member of your team working 100% and have slow  product development as the team isn’t working together.  Additionally,  the concept of needing to achieve 100% utilization leads very naturally  to multi-tasking…
  • Multi-tasking isn’t that costly – FALSE
    • Multi-tasking is amazingly expensive, not just because of the  individual person’s loss of time due to context switching but also  because it promotes the individual at the cost of the team.  If my team  has a DBA for 20% of the time, and we already used our 1 day for the  week, what priority will we be in his / her queue when more database  work is needed that week?  Beyond that, how vested can he really be in  the success and knowledge of the product with limited implied commit?
  • Resources (dev, testers, IX, UA, BA) are just commodities and should  be passed around where needed – FALSE
    • I have seen this a few times in large organizations, this concept  that we can just move around skills as needed.  It doesn’t work.  Sadly  this happens predominantly to testers – ‘We need 4 testers next week to  smoke out this app.’  How is this fair to testers?  Testing is an art –  the ability to know how to break.  But it is more than that.  For  testing to be most successful, domain knowledge and  customer  expectations for an application are critical.  That knowledge is not a  commodity that is easily passed around cheaply.

What should we do about this?  For starters, simply stop referring to  people as resources. That is the easy step one.  Then start believing  it – invest in agile teams.  Teams that own a product or feature.  They  function as a team, have all the skills on their team to deliver, and  are measured not on their individual time sheets but on the progress and  overall success of their delivery.  Create and foster team ownership  and promote healthy dialogue not only around current implementation but  also a collective view on future direction.  Then start reaping the  benefits.

There are many factors that will determine a company’s success in  adopting agile practices.  One that each company must look at is whether  or not they can truly let go of the view of people as resources and see  them as product thought leaders.

Read more by Joel Tosi @ communalosmosis.com

This entry was posted in Agile Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>