Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Jun 16, 2010 — Enterprise Agile Planning expert

How many printers does it take to build your application?

Enterprise Agile Planning


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 @

The post How many printers does it take to build your application? appeared first on VersionOne Blog.


More from the Blog

View more
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Contact Us