# 2.1 Current Performance
The best plan in the world is useless if it isn’t implemented successfully — the effectiveness of your team’s current performance depends directly on the quality of your processes. Your company’s level of performance is a reflection of how effective you’ve been at translating goals into outcomes and maintaining a consistent degree of quality.
# 2.1.1 Product Performance Outcomes
Level: Basic
Your released products are meeting their adoption and retention goals. User satisfaction is high, and current user satisfaction feedback is either stable or improving.
For already deployed products, the success of the product at attracting and retaining a userbase is arguably the ultimate measure of a project’s performance. Those numbers are lagging indicators, so additional attention should be paid to trends in user satisfaction feedback and data, which are leading indicators.
# 2.1.2 Outcome Achievement Rate
Level: Basic
Your team’s current development process provides an effective framework for achieving core outcomes, as evidenced by your team’s consistent ability to meet its iteration goals.
You and your teammates’ level of satisfaction with your teams’ development process may offer insight into whether the team’s current level of performance is sustainable long-term. Key metrics—such as the consistency with which the team meets its iteration goals—can be used to provide a more objective measure of the quality of the team’s development process.
# 2.1.3 Incident Rate
Level: Basic
Your team has had no major incidents (e.g., with product performance, availability, etc) in the last three months. If any did occur they were resolved quickly and steps were taken to prevent recurrences.
The ability to prevent and resolve major failures is an existential competency. Major failures can impose significant costs in the form of financial and reputational damages, and even the strongest business model can become unviable if a failure is severe enough to prevent adherence to its tenets.
| Suggested metric | Description |
|---|---|
| Time to Restore | For a specific application/service, how long does it generally take to restore service when a service incident or a defect that impacts users occurs? |
# 2.1.4 Team Performance Evaluations
Level: Intermediate
The team is treated as the smallest unit of performance in the company. Work is assigned—and performance is evaluated—at the team level, not at the individual level. Evaluations show that your team is performing to a high standard.
Team-level performance is far more relevant to the success of any team initiative than individual performance is. Focusing on team outcomes instead of individual outcomes also has positive psychological effects—it supports team accountability, promotes investment in each other’s work, and gives everyone a shared stake in each other’s success.
# 2.1.5 Development Velocity
Level: Intermediate
Your team uses a framework to measure and define its productivity goals. This framework shows that the team's development velocity is satisfactory.
Development velocity describes the amount of work that a team can complete in a given time period. Development velocity is an important metric that can be used to set measurable productivity goals; however, care must be taken to ensure that increases in velocity do not come at the expense of quality.
# 2.1.6 Architecture Quality
Level: Advanced
The team has an effective documentation and review process that is used, on a regular basis, to confirm the quality of its system architecture and identify opportunities for improvement.
The use of a strong documentation and review process for your team’s system architecture should provide insight into the system’s stability, usability/efficiency, and overall ability to meet your team’s business needs. This process should be standardized so that the results of each review can be directly compared to each other.