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
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us