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
The post How many printers does it take to build your application? appeared first on VersionOne Blog.