Here is the usual explanation:
- Efficiency is about doing things in the most cost-effective way – it refers to the ability to use resources in the most economical way possible in order to accomplish a task or a goal. It is most often measured in the number of units produced per time interval (e.g. hour, day, week, etc.) of work.
- Effectiveness is about achieving the desired goal or objective – It refers to the ability to achieve a desired outcome or goal. It is often measured in terms of how well the output of a process or system meets the desired results or objectives.
While many favor one over another, both are important in any system or process.
Of course, both are important aspects of the work results of a software development team as well. They answer the usual questions:
- How many items can the team finish? (how efficient are they?)
- How effective is their result? (what is the outcome of their work?)
The discussion mostly ends there, for most of the teams and organizations. However, although correct, this perspective is just superficial and there is more to it!
Instead, it is important for teams to consider efficiency and effectiveness from many other perspectives, e.g. knowledge distribution, design decisions, various types of testing, etc.
In other words, it is not just how many items are produced and how good are results, but also how better the team and the product are becoming after each increment.
Those perspectives are repeatedly ignored and overlooked, but they are extremely important. Read on to find out why.
NOTE: Given the similarity of meaning of the terms efficiency and efficacy, they are used as synonyms within this text. The difficulty in explaining the difference to non-native English speakers solidified the decision further.
Effectiveness and efficiency of knowledge distribution
While developing a software solution, teams often have to acquire new knowledge. This knowledge acquisition comes in many forms and under many different names. Here are some:
- validation of assumptions / conducting experiments,
- proofs of concept/spikes,
- learning new domains/concepts/tools,
- etc.
Facing such knowledge acquisition items, teams frequently respond by “being more efficient” and assigning such tasks to individuals. On the surface, this might be a perfectly reasonable approach – assigning an individual to acquire new knowledge and possibly compile it and transfer it to other team members.
Unfortunately, although this might be efficient, it is not as effective. Knowledge cannot be “implanted” into others – they have to undergo a similar learning process, specific to their own mental models.
Being primarily a learning activity, the quality of software development suffers greatly within teams with ineffective knowledge distribution.
So beware of the pitfall – teams need an effective knowledge distribution, so do it at expense of the efficiency of the learning process if necessary.
There are very effective ways to do so (e.g. this and this)
Effectiveness and efficiency of design decisions
Similarly to the previous, teams often opt to distribute work among individuals, regardless of its type. So it is more often than not that teams assign large items (e.g. stories or complex use cases) to individuals, leaving the design decisions to them (or at least some of “the more granular” design decisions).
Although (arguably) being more efficient this way (more done per day), this often backfires in decreasing quality, emergency rework (often triggered by async code reviews), increasing complexity, and reinforcing knowledge siloes within the team.
To avoid such a trap, opt for a more effective way to make design decisions within a team (e.g. as described e.g. here and here).
In the end…
Although efficiency is very important, teams have to also be aware of dangers lurking when mostly focusing on it.
Efficiency and effectiveness are often disregarded by developers as “the process mumbo-jumbo” but it is extremely important to understand both terms properly and understand them from various perspectives of the teamwork context.
Mostly focusing on efficiency, disregarding all the effectiveness aspects discussed above, causes the teams to suffer and often grind to a halt.
So pay attention to those and find the right balance between the two – efficiency and effectiveness.