What Questions Tell Us About Agile System Design

In organizations that use Kanban, teams evolve their existing practices incrementally to improve service delivery. In contrast, organizations adopting framework-based approaches like Scrum typically undergo more dramatic changes, introducing new roles, responsibilities, ceremonies, and artifacts all at once. In these Scrum environments, rapid structural changes lead teams to face numerous challenges as they navigate the new system and ways of working.

Beyond new roles and ceremonies, an agile transformation requires teams and leaders to adopt new principles and values. The questions team members ask as they figure out new systems indicate process gaps, but also reveal how well the organization is absorbing those new Agile principles.

For example, a team using Jira for the first time might ask: “How do we track the progress of Epics?”

While answering the question directly is an option, a more effective response begins by analyzing why the question was asked in the first place. The question itself reveals something about how the organization works. Instead of focusing on the mechanics of tracking Epic progress, work with people to better understand why tracking is needed and what it reveals about the broader system.

Questions Are Leading Indicators

Leadership typically evaluates agile transformations using delivery metrics such as cycle time and throughput, as well as agile maturity models. These metrics indicate the effect of new practices on team performance weeks or months after new ways of working are introduced.

The questions team members ask provide real-time clues about certain aspects of the system’s health. When a team asks how to estimate an epic, they are sharing a quality of the system that could greatly determine the organization’s overall agility, which would otherwise never appear on a dashboard.

Metrics dashboards do not capture team uncertainty, operational gaps, or cultural friction. Clues to these problems surface in retrospectives, daily team collaboration, and informal conversations. The questions teams ask during daily work provide immediate feedback regarding system design, organizational culture, and the adoption of agile principles.

Four Example Questions and Their Causes

1. “How should we track progress on Epics?”

• The systemic cause: The organization tracks progress through status reports on work in progress rather than on the delivery of working software. Teams are expected to generate traditional project status updates and attend progress reviews, increasing administrative overhead.
• The coaching response: The demand for epic tracking usually stems from large projects with long lead times, complex dependencies, and low trust that teams will deliver on time. Address these issues and shift the team toward more frequent, incremental releases. Teams are freed from manual status reporting when they can regularly showcase deployed software.

2. “How do we track individual effort and capacity?”

• The systemic cause: This echoes the factory era, in which workers were treated as interchangeable units of labour. It surfaces wherever individuals are planned, budgeted, and tracked as distinct “resources,” and management measures individual utilization rather than team-based throughput.
• The coaching response: Shift budgeting, planning, and performance management from the individual to the stable team unit. Implement a fixed-capacity team model, funding and forecasting based on the team’s established delivery history rather than individual hours of effort. This focus moves the conversation from resource utilization to team flow.

3. “How should we estimate this work?”

• The systemic cause: Teams rely on estimation because delivery schedules are unpredictable. Estimates are frequently used to measure team velocity, track individual capacity, or prove that a team is fully utilized.
• The coaching response: Teams are better off not estimating work. Instead of estimates, a better focus would be on the flow of work, handoffs, and understanding what causes delays. Reduce wait times to establish predictable cycle times. Shift the team’s focus away from upfront estimation and toward tracking lead-time trends.

4. “Who is supposed to write the user stories?”

• The systemic cause: User stories are treated as formal, static requirement documents handed off between roles. Teams collaborate on user stories based on rigid responsibility matrices, reinforcing a siloed interaction model.
• The coaching response: Reframe user stories as the product of team discussions about what users might want. Those discussions build a shared understanding across perspectives about which customer problems to solve and what needs to be built. The story artifact is simply the record or the note that best supports that process and captures its outcomes.

How Coaches and Leaders Should Respond

When teams ask operational questions, organizations that favour consistency and standardization often respond by creating new rules, templates, or procedures. While this provides an immediate answer and supports consistency, standardizing processes undermines agility.

When the overarching goal is standardization, what you end up with are highly codified, context-free procedures. One issue with this approach is that it bypasses the deeper investigation needed to understand system conditions. The rush to standardize freezes the organization into specific ways of working, making future adaptation harder, slower, and in the hands of governance approvals instead of in the hands of the teams:

• Context is ignored: Standardized policies assume every team operates under the same conditions and that a single rule will have the same impact everywhere.
• Investigation is replaced by compliance: Instead of exploring why a question was asked or mapping the conditions that led to it, coaches and leaders are forced to ensure that teams follow the correct procedures.
• Learning is minimized: When people follow prescribed processes, they don’t learn for themselves. Teams fail to develop the internal capability to solve their own problems in the future.
• Rigidity increases: Processes become difficult to adjust once codified into official standards, sacrificing adaptability for uniformity.

When asked operational questions, refrain from handing out a standardized set of instructions. Instead, consider trying one of the following three approaches:

Analyze the root cause before prescribing solutions

When a team brings an operational request, avoid jumping straight to a solution. Questions usually arrive as fixed conclusions, “How do we do X?” which are often several steps removed from the real issue. Take time to explore what environmental pressures, policies, or trust gaps prompted the question in the first place, so you help people solve the actual problem rather than add another workaround or band-aid.

To make the systemic context visible, sketch a problem tree or lightweight systems map together. Trace how the question connects to the workflow, handoffs, stakeholders, or other processes related to the request.

Guide with principles rather than fixed recipes

Agility relies on teams developing their own problem-solving capability. When teams ask a question, instead of offering a direct answer, try to find a relevant principle or story to help them decide for themselves. This approach helps teams build judgment and make context-appropriate choices more independently.

Try helping them write down the original question or challenge, capture what they want to happen as a result, identify which Agile principles or values are relevant, and, lastly, think about what a solution that aligns with those principles might look like.

Watch for recurring patterns

Pay special attention when one-off questions start becoming recurring themes. When the same question appears across multiple teams, it indicates a structural issue in how the organization has designed its teams, or broader governance, or cultural issues or trends.

A question log, or surfacing these questions in various team and department-level retrospectives, can help identify these trends. This data enables you to address broad organizational constraints with leadership rather than treating the same symptoms repeatedly at the team level.

Agile transformations are typically measured by what teams produce. However, analyzing the questions teams repeatedly ask provides an earlier, more accurate diagnostic of organizational design and systemic health.