Innovation and Problem Solving in Agile Management: How to Achieve Greater Impact with the Resources You Have

After exploring short-iteration work and iteration planning, the next logical question is how teams find better solutions when conditions are unclear, resources are limited, and the “obvious” approach does not work. This third article in the series focuses on practical approaches to innovation and problem solving: how to frame goals so they produce measurable impact, how to identify the system’s real constraint, how to gather reliable input from users, and how to use constraints as a tool rather than an excuse.

Why innovation is a management discipline, not “inspiration”

In business, innovation matters only when it creates value. That means using existing resources deliberately to achieve a stronger result: higher productivity, lower cost, shorter lead times, better quality, or better service.

The key management principle is that initiatives should deliver benefits, not just “complete activities.” A benefit should be understood as a change in the organization’s capabilities and should lead to a positive return on the effort invested. If we cannot measure the effect, we risk optimizing “activity” rather than outcomes.

Benefit and measurement: how to talk about value without abstractions

Before choosing a solution, it helps to answer three practical questions:

1. What change are we aiming for (in money, time, volume, quality)?
2. What is the current state (a baseline)?
3. How will we measure the new state after implementation?

A baseline is critical. Without it, every assessment becomes an impression. Even a simple set of indicators is enough: cycle time, number of errors, rework cost, complaints, scrap, downtime, energy consumption, on-time performance.

It is also important to define the “new cost” realistically: not only the investment, but implementation, training, ongoing support, and the time of the people who will operate in the new way.

Example (logistics): the goal might be fewer picking errors and shorter time to prepare a shipment. Measurement starts with today’s errors per defined volume and average preparation time. Then you run a pilot in one area and compare results.

Why projects miss their targets and what that means for management

When initiatives fail, the reason is rarely “lack of effort.” More often the problem is managerial:

• goals change during execution, without a clear decision on what drops
• requirements are captured inaccurately or expressed as solutions instead of needs
• risks and unknowns are underestimated
• there is no shared vision and communication across functions is weak

A practical conclusion is that innovation must address three tasks: alignment on goals, accurate requirements, and management of uncertainty. If an initiative stalls, the root cause is almost always one of these three.

Focus on the system: the constraint as the fastest lever for impact

Many improvements do not produce results because they target the wrong place. An organization is a system, and it typically has a constraint that sets the pace of the whole flow. If we improve outside the constraint, we often just increase work-in-progress and waiting, without any real increase in output.

How to identify the constraint in practice:

• where queues or “waiting work” accumulate
• where flow most often stops
• which role, machine, or decision blocks others
• which step ultimately dictates end-to-end speed

This perspective shifts attention from “local efficiency” to overall outcomes. In many companies, one area can run at maximum effort while deadlines still slip because the constraint is elsewhere.

Continuous improvement with a clear sequence

Effective improvement follows a logic that prevents premature investment:

1. identify the constraint
2. get the most out of it with existing means
3. align the rest of the system to support it
4. increase capacity only if needed
5. repeat the cycle, because the constraint will move

This sequence matters. Many organizations jump straight to “buy or implement something” before they have exhausted process improvement and before surrounding functions are adjusted to support the real constraint.

“Know the user”: why experts often get it wrong

A major underestimated risk is building solutions on assumptions. Often the expert is not the real user of the process. This is as true for internal systems and procedures as it is for customer-facing products.

A useful distinction:

• “putting yourself in their shoes” (guessing how someone thinks)
• “taking their perspective” (asking questions, observing work, verifying the real context)

Practical methods:

• short interviews with frontline people
• observation on the shop floor or in the office
• tracing an order or request end-to-end
• a limited pilot before scaling

The goal is to reduce the risk of optimizing something that sounds logical but does not solve the real problem.

The power of a story: clearer understanding, fewer disputes

When a problem is described through a concrete scenario instead of abstract requirements, teams reach agreement faster. A story has a character (who), a need (what), and a motivation (why). This shifts discussion from “who is right” to “what need are we solving” and “how will we know we succeeded.”

This is a practical tool for cross-functional work when perspectives differ and priorities compete.

Good need stories: from “what to build” to “what need to solve”

A good story describes:

• who has the need
• what they want to achieve
• why it matters

Then we add:

• assumptions (what we accept as true)
• acceptance conditions (how we will verify success)

The key is that the story describes a need, not a solution. It should be short and provoke questions. Assumptions bring hidden beliefs to the surface. Acceptance conditions make the goal verifiable.

Example (service): “As a service coordinator, I want a standard first-diagnosis protocol so we reduce repeat visits and speed up repairs.” Then define assumptions and acceptance conditions: adoption rate during the pilot, reduction in repeat visits, time to first assessment.

Visibility and early validation: fewer mistakes, cheaper corrections

The earlier we validate our understanding, the lower the cost of being wrong. That is why visual tools and early tests are useful:

• a process map of “current state” and “target state”
• a simple prototype of a form, screen, or label
• a pilot batch or a test period in one area
• measurement before and after the change

This enables correction before investment in scaling.

Constraints as a driver: smaller batches, less risk, more learning

Constraints can accelerate progress when used deliberately: limited scope, limited time, a small team, small “batches” of work. Smaller batches enable faster feedback and more precise adjustments. This is particularly valuable for small and medium-sized companies, where the cost of a large mistake is high.

Practical applications:

• a pilot in one line instead of all lines
• start with one product group
• start with one warehouse zone
• start with one team or shift

Managing uncertainty: tactical, technical, and business responses

When unknowns are high, it helps to think in three directions:

• Tactical: postpone detail until information is available; clarify the riskiest items early
• Technical: reduce dependencies, define clear interfaces between functions, isolate complexity
• Business: monitor the environment, involve different competencies, engage key roles early (quality, safety, IT, finance)

This reduces the risk of discovering too late that something blocks implementation.

Resolving contradictions: when it looks like there are only two bad choices

Many organizational disagreements are trapped in a “either/or” frame. Often the contradiction is in the assumptions. Once those are surfaced and tested, new options appear.

Example: “Either we move faster or we protect quality.” If we reduce batch size and introduce earlier checks, we can move faster and reduce defects at the same time.

How to apply this as the next step

A practical sequence:

1. Frame the goal as a measurable benefit and establish a baseline.
2. Identify the system constraint and focus improvement there.
3. Gather perspective from real users.
4. Describe the need as a story with assumptions and acceptance conditions.
5. Run a small pilot and measure the effect.
6. When conflict exists, challenge assumptions, not people.
7. Repeat the cycle, because conditions change.

Conclusion

Agile management is not only about cadence and planning. It is a systemic way to find solutions under uncertainty: measurable goals, focus on the constraint, real user feedback, small pilots, visible assumptions, and verifiable success conditions. This reduces the cost of being wrong and increases the likelihood that initiatives deliver real impact instead of merely “completing activities.”

The Ruse Chamber of Commerce and Industry is developing this series to support regional businesses with practical management approaches that speed up the adoption of useful changes and strengthen competitiveness.

If you would like to discuss how these approaches can be applied in your organization, contact me at sminchev@rcci.bg or +359 895 890 123.

Note: The publication was prepared with the help of generative artificial intelligence, which assisted in structuring and formulating the content. The final text is the result of the author's expert contribution, which guarantees its accuracy and practical focus.