Efficiency in Agile Teams

Neither efficiency nor efficacy: Effectiveness

Recently, in a conversation with some workmates, a common question in the agility community arose: How can the efficiency of our team be measured?

Quickly, the need to know the Team Velocity came up. At that moment, I commented, “But efficiency is not just a velocity question, right?”. Before answering this question, it would be necessary to understand what being an efficient team is.

Some acronyms in this article:

• DoD: Definition of Done
• DoR: Definition of Ready
• MVP: Minimim Valuable Product
• PO: Product Owner
• SM: Scrum Master

Efficiency in comparison to efficacy

Efficacy is directly related to objectives achievement. When taken to an extreme, efficacy apparently doesn’t include limitations and uses the means that are necessary for achieving the established objectives.

Efficacy is the secret dream of a traditional project manager who is involved in planning. For any project, the project manager wishes for unrestricted time to do it, anyone with those resources that are necessary, and an unlimited budget. In summary, efficacy consists of using whatever you need to obtain what you want in the best way possible.

In terms of efficacy, it doesn’t matter if these means are used in an optimal way. If these means achieving the objectives, it is fine. This scenario is not as strange as it seems. Probably, you have lived in any situation where your talent and knowledge could not be used to the maximum. This seems good for efficacy, but is not fine for you, is it?

A project can go well from the perspective of efficacy, but even so, it may be creating a disaster from the point of view of people who are collaborating on the project. On a large scale, in the real world, there are always limitations. As a society, we are used to aspiring to get everything we want, even though we know there are no unlimited resources.

Efficiency is related to the appropriate use of available resources. In projects, the main limitation, or the most evident one, is the cost. Someone decides that a certain product or action has a cost ceiling. This cost is decided through a tender, a commercial offer, or any other estimation. But, apart from the cost, it is a common fight with:

• Resources limitations: It is never possible to dispose of all resources (people and infrastructure). This is especially evident when it comes to cost constraints because they can prevent a balance between human resources and rates.
• Deadline limitations: The recipients, the customer, or the market doesn’t wait indefinitely when the necessity to cover it is usually urgent.

Efficiency consists of being aware of the tools that we have and using them in the best way possible to obtain the desired results.

Velocity is not the only variable to define efficiency.

If, in our project’s scorecard, we only looked at the speedometer, maybe we would find an efficient team is slower in comparison with an effective team. We must understand that both teams are playing with different rules. An efficient team has restrictions and focuses on squeezing out most of the available tools. Meanwhile, effective teams don’t have restrictions and use all the tools they must maximize results.

It would be suitable to look at other parameters, which, in addition, are very interesting, and they could help us to have a 360º image of the efficiency in our team. Some of these parameters are:

• Lead time and cycle time analysis
• Quality aspects of the Scrum Board and backlog
• DoD and quality compliance
• Bugs and their impact on planning
• Evaluation of the obtained value
• Evaluation of satisfaction

Lead Time and Cycle Time analysis

Do you think it is positive for the team that we focus only on time control? The Cycle Time includes only the necessary time to build a necessity once it is authorized. This time is for the technician, and it is time to find the technical solution to the need.

But what happens with all the previous processes? Doesn't a bit of focus pay off? In the same moment that a stakeholder verbalizes a necessity a process begins that has a main objective: Determining its suitability for the entire product. Both regarding the already-built part of the product and the pending part.

This process has a workflow that, basically, chases to obtain the necessary information to determine its suitability. Therefore, this process involves the work of people and teams for a certain time. And how it can (or must) be evaluated and measured as part of the entire process.

Lead Time has a vision of the entire process. Since the necessity appears, until a product or solution is available. This vision of the complete process allows seeing where some obstacle or inefficiency can be. Technical processes are very efficient (cycle time) in a very slow needs management process (lead time), or vice versa. This information helps us to focalize our efforts to improve the process.

This whole process is susceptible to improvement. A slower Lead Time can cause problems in the prioritization, and it affects the quality of the results of the value that is delivered. It may require participation of Scrum Masters to explain to the organization how to improve their collaboration in this process.

Quality aspects of the Scrum Board and Backlog

In an Agile framework, the team mission is to be completely self-organized. But unfortunately, self-organization ends where organizational rules appear. It is an uncomfortable reality, and we need to know how to work with it.

For example, there are organizations that don’t know or don’t understand how to use the User Stories concept. The Product Backlog can be a very useful tool for the team, with clear, updated, valuable, and well-informed (“Ready to do” concept) elements. Or it can be a dead end with items without order or consistency.

The Team Scrum Board is a reflection of Product Backlog. If the Product Backlog weren’t well, the Scrum Board wouldn't be well. As a Scrum Master we must detect this and make proposals to improve the quality of the team’s tools. Clean and clear Scrum Boards. Clear and achievable objectives in sprints. Value orientation. Product Backlogs are focus on need, acceptance criteria, and MVP.

As a Scrum Master, we would do well to have quality indicators about team tools in our scorecard.

DoD and quality compliance

A team that prioritizes efficacy will not see well-restrictions, rules, or activities that could endanger the achievement of its objectives. On the contrary, an efficient team is mindful of these rules and will adapt its operation to incorporate them as part of the result.

DoD is everything the organization (for ex: CI/CD), the customer (for ex: usability and accessibility), the state (for ex: Data Protection Act), and the team itself (for ex: API, scalability, quality rules) believe is necessary to have the desired results.

Additionally, this set of tools and rules must place emphasis on quality objectives, tech quality, and reliability. For example: Multilevel testing, performance benchmarks, and, especially in iterative cycles of development, regression assurance. The DoD try to say that having a product that works is not enough, but this product must also be useful in any situation.

When they ask us how we can measure the efficiency of our team, we should have values about DoD compliance.

Bugs and their impact on planning

Usually, when we deliver something as part of our sprint, sure it will contain some errors or surprises, for sure. Users will be alerted about these bugs when they make use of the product. As a Scrum Master (as a part of our responsibility to promote team efficiency), we will measure the bugs that appear. We need to know the origin, the way they will be resolved, and the impact on teamwork, as well as the expected results in the next sprint.

I can’t explain all the mechanisms here that work and solve bugs. But there are some details I would like to explain because I think they are important:

1. Not everything is a bug. A bug is a malfunction related to an expected result. Any request that doesn’t comply with this rule is not a bug. It can be an evolution, a new necessity, a change in a process or business. In any case, a request that is not a bug is simply more work on the backlog.
2. Not every bug is equal. The bugs must be classified. Because not all bugs put the continuity of service at risk. Therefore, we have to pay attention immediately to the bugs that put the service at risk; we will postpone all of them that, although they are annoying, don’t seriously impact the service; and we will delegate everything else. The team is not customer service.
3. There isn’t exist a single way to treat bugs on your team. Without knowing the dimension, we don’t know how serious the impact of a bug can be with respect to the committed work in the current sprint. The main thing would be to have an estimation of this impact. Once we know this, we can agree on some of the next strategies:

• Have a support team dedicated to bugs.
• Reserve a time in every sprint to resolve bugs.
• Dedicate people and hours to resolving bugs (it is not a good practice for me)
• Create refactoring sprints.

Either way, I think the important thing is to make estimations about these bugs when they arrive. With this estimation, you can explain to the Product Owner that this work to solve bugs is work, too. The work is never at zero cost.

Evaluation of the obtained value

If you dispose of an iterative system that consists of giving, in cycles, a portion of the product, this portion must be useful for its recipients. If that is not the case, this delivery will end up in a drawer, waiting for other deliveries, or even worse, to have all the product ended.

If our deliveries ended out in drawers, then we wouldn’t have feedback and reviews that would allow us to detect and correct deviations. And very probably, this fact would negatively affect the project.

An activity to define a correct MVP is part of the process of Lead Time. In our mission of constant evaluation of our team, we should see indicators about MVP definition and its compliance in every delivery.

Evaluation of satisfaction

The last concept of this article corresponds to the evaluation of satisfaction. This aspect is usually the most forgotten in the Scrum Masters scorecards and tools. In the opinion of many experts in management and Agile good practices, they think that this is the most important objective. Happy customer, happy team.

There are various ways to find out the satisfaction of all parties, but the most effective is by placing inputs in the Sprint Review:

• Did the delivery comply with your expectations?
• Has there been any change from the initial plan for this delivery? Has this change been properly communicated?
• Has this delivery been integrated with the rest of the product?
• Have many requests been generated for the user service?

We do not forget that satisfaction is never exclusive to users. They are important, but they are not the only ones. Satisfaction is also a team objective. We have a cyclical opportunity to evaluate the satisfaction of the team. The Retrospective activity:

• Did what was planned for this sprint match the expected dimension? Can we learn anything about this?
• Were the committed items “ready”? Have you had problems to achieve the DoR?
• How is the DoD? Does it need any changes?
• Did any impediments come up? Have these impediments exposed the delivery to any difficulty or put it at risk? How were they managed? What has been the role of SM role in these situations?
• Was the PO accessible enough? Has his collaboration been valuable when the team asked for help?
• Did the compromised items contain valuable acceptance criteria? Have they served to guarantee the value of the delivery?
• Have you had enough context for the whole set of committed items as a single deliverable piece? Has there been any dependency?
• Are there any missing skills? Can it be replaced? Is it necessary to do any action about it?

Neither efficiency nor efficacy: Effectiveness

As we read, the efficacy consists, in the extreme, of doing everything you wish with all the resources that are necessary. To obtain this objective, cost, real quality, or talent of the people doesn’t matter in front of the results.

On the other hand, we have efficiency, which consists of taking advantage of all resources. In this case, the quality of the results, the appropriate use of people’s talent, the maximization of resources, and the vision of the global process are more important than the speed to have the product.

Effectiveness consists of acquiring enough awareness that we will be effective when we achieve the established objectives (efficacy) with the maximization of disposable resources and tools (efficiency).

To have an effectiveness team, the Scrum Master needs some skills and tools that allow him/her to have a 360º vision of the team situation:

• A good definition and a good comprehension by the team about DoR (Definition of Ready), DoD (Definition of Done) and quality compliance.
• A correct agreement about how to manage bugs and changes.
• An enough agreement about the organizational, legal, or technological rules that every delivery must comply with. That includes the assurance of regression and continuous product integration.
• A complete process to evaluate the value obtained every cycle. That includes a good understanding of MVP (Minimum Valuable Product) and a good practice of the Review routine.
• A constant observation of the backlog. Its quality and the appropriate participation of the Product Owner and the Team. The backlog is part of a big process to determine the authentic necessity.
• The presence of open communication channels with all involved stakeholders
• A good vision about the team’s internal rules, documents, and routines to manage the ordinary work while needing to manage quality assurance, changes, impediments, bugs, risks, and dependencies.
• A deep knowledge about the mechanisms to constantly search for continuous improvement. In technical skills, appropriate resources, and team needs.

The world doesn’t work with only efficiency or efficacy. We need to find a balance between these couple of factors. This is effectiveness.

Read the complete article in: