I get this question frequently from teams that are new to Agile. Here are some of their concerns:
1. If you do not have detailed plans up front or if the plans keep changing, is that efficient?
2. How can you be efficient with the overhead of all the Agile meetings?
3. Design/code/test in small increments is inefficient because of constant context switching.
4. Agile recommends that team members help each other out to meet the Sprint goals. We have resources with specific expertise and specialities. It is not efficient for them to do something that they are not expert in.
5. Sprints always end at the same time, but my work doesn’t thus interrupting my flow of work and making me inefficient.
Efficiency is defined as a ratio of the output to the input of any system. To improve efficiency, we can maximize output and/or minimize the input. If our sole focus is on minimizing the input without regard to maximizing the output, we will miss the boat. Hence it is important to analyze the context for efficiency for each of these concerns and determine which ones offer a better overall value.
In the first concern, the efficiency is in the context of the project plan, how well it represents reality and how close is the execution of the plan to reality. This measures the efficiency of the planning process and how well the team is executing with respect to the plan. The premise here is that we can accurately identify detailed plans up front and they will not change as the project progresses hence measuring plan vs actual is a good metric of progress. If this premise is true, then Agile will be inefficient for the project because Agile is based on the assumption that it is difficult to plan all the details up front and the plans will change during the course of the project. Hence Agile planning is incremental, time boxed, and delayed. Planning in Agile happens at a high level during release planning, and gets incrementally detailed and refined during each of the sprints. This way you get the benefit of planning the big picture without the overhead of maintaining the details as the plans change. During the sprint planning, team identifies the detailed tasks and they may have an overall idea about the sequence in which they will be performing the tasks but they are not putting it on a timeline. This happens during the daily standup call, when each team member tells the rest of the team which task they plan to take up that day. This delayed approach to scheduling allows the team to have more realistic and accurate schedule.
In the second concern, we are talking about the most efficient utilization of everyone’s time. If the tasks for each team member are well identified, they do not have any dependencies on each other, there are not expecting any roadblocks and most importantly they do not need to collaborate with each other to plan or design, then Agile meetings are an overhead. On teams that time box their meetings appropriately, the overhead of all Agile meetings is no more than 10%. This is a small price to pay to improve the utilization of the remaining 90% of the time. Even if you overlook the innovation aspect of collaboration, most teams are able to cut down their effort significantly through dialogue and discovery during these meetings.
In the third concern, we are talking about is the efficiency of grouping similar tasks together. (I still remember my coursework in industrial engineering that talked about optimizing manufacturing tasks with things like time studies, etc.) This industrial engineering approach works well if the tasks are well-defined/understood, repeatable, the components will always work well together in the final assembly and most importantly will not benefit from receiving feedback on your interim work from the customer. If these assumptions are correct, then waterfall approach will be more efficient. Agile believes that by showing smaller increments of work to the customer and rest of the team, you are getting continuous feedback (before you go too far with the implementation), the integration issues will be much smaller and it gives team an opportunity to reflect on the work so that they can improvise. The assumption here is that is more important to get the right thing to the customer even though it may be little inefficient than getting something to the customer in a more efficient manner. With the iterative and incremental approach, many teams are able to deliver what ordinarily would have been a “Release 1.3” version of the feature in the “Release 1.0” timeframe thus improving your odds that customers will benefit from the new feature and in the process improving your competitive advantage.
In the fourth concern, there is a trade-off between efficiency of an individual over the efficiency of the project in getting the most critical feature to the customer. When team members help each other out to meet the goal of the sprint, they are certainly helping the project to get the most critical feature to the customer on time but in the process they are also improving teamwork and morale for the team. In one team, when the developers helped QA in completing their work for the sprint, they developed new respect for the complexity and importance of QA work that significantly improved the collaboration in following sprints.
In the fifth concern, the trade-offs are similar to the third concern. Yes, it is less efficient to interrupt the flow periodically to get feedback from the team and the customer, however if it improves the odds of building and right feature for the customer and reducing integration risks, then it is a good trade-off.
In conclusion, Agile will be inefficient if your project has well-defined and stable requirements, has no risks and will not benefit from continous collaboration with the team and the customer. Agile will help you deliver what the customer wants efficiently under the chaotic conditions that exist in most software development projects. Teams often get too hung up on the efficiency of an individual resource or a process step thus focussing primarily on minimizing the input and ignore the effect of that action on the output.