Economies of experience and Agile development

We always hear about economies of scale and scope. Do we ever think about how do these two concepts apply to software development? Let's consider economies of scale first. If we get more developers, we maybe able to negotiate lower rate from our vendor. Another way to look at it is the larger the project size, the lower the rate per hour of development. What about economies of scope? When we develop software, we could design it in a way so that we can end up with a set of reusable components. We could then use these reusable components and build our next software for an adjacent/related domain quicker. Building the first application will cost more. The successive applications should cost less. Thereby we achieve economies of scope. Here is one more reason to ask your boss to invest in OO on your project.

OK, you probably already know this. The reason I brought this topic up is to introduce another related concept that I call economies of experience. I don't hear anyone talk about this in the software industry. In manufacturing, there is a similar thing called experience curve. How exactly does economies of experience apply to software development? When we hire developers for a project, we all look for individual experiences in a developer with the technologies and in the domain the project is. The longer a developer works with a technology and in a domain, the more productive he/she is with that technology and in that domain. We, however, never think about experience at a team level. Developers maybe individually very productive, but when they work as a team it is completely different ball game. Like an individual, a team also needs nurturing to be able to unlock its fullest potential. In the abscence of active coaching and guadanice, a team can end-up crashing and burning.

Every team has a unique DNA. The DNA emerges over time. The longer a team works together, the more productivet the team gets. That is why Agile/Scrum uses a drag factor (negative productivity) in estimation. We increase the total estimate by this drag factor. A team working together for the first time may start at 40% drag or 60% productivity. Usually, it takes a year for a team to reduce drag to 0 or reach 100% productivity. Anytime a team member leaves or a new team member joins, productivity of the team goes back down.

In traditional project management, resource planning is done using staggered or just-in-time approach. We bring a developer on board only when we have a need for his/her skills. The thought there is that we would save money by engaging people only when they are needed. However, this (the savings) is seldom achieved. The further along the project, the higher the impact on team productivity for adding a new person to the project. That is why Agile projects make a reasonable effort to recruit the full team upfront with people who will be able to wear multiple hats. In the long run, the savings come from higher overall team productivity and utilization.