What do agile ways of working have to do with innovation?
The call for "agile organizations", "agile working methods" and "more efficiency" with "more innovation" is loud. Nevertheless, we sometimes have the impression that very different things are associated with these buzzwords. Agile, for example, often does not stand for a clearly defined form of teamwork that makes sense for certain requirements, but for a rather vague feeling of "processes must be faster and less complicated", "flatter hierarchies" or something similar.
This means that agile ways of working are introduced in environments that are not actually suitable for it. And the drastic changes that this type of teamwork causes in management culture, stakeholder management and team culture are either insufficiently or not at all supported by leadership. When, in a highly volatile environment that would have benefited from agile teams, we told the responsible manager that she could no longer simply "throw something into the team", but had to wait for the next sprint or revise the requirements together with the team, the decision was made quickly. The manager, who was initially in positively inclined to training the teams in agile ways of working, simply said "out of the question". As a result, introductions of agile work often fail, especially outside the IT environment, and degenerate into a fig leaf initiative.
And where does agile teamwork with an emphasis on iterative procedures within a clearly defined work process, cross-functional teams, a focus on the production of a usable product part (minimum viable product), prototype logic or the ability to respond quickly to changes in requirements make sense? Exactly in environments that are VUCA, volatile, uncertain, complex and ambiguous, where things change quickly or something has to be made available quickly - and a 70-80% solution is enough to be tested. Product perfection is not the first goal of agile work, but usability. Subsequent sprints, in which initial user feedback provides useful hints for further development, will improve the product.
It is therefore obvious that accounting is not the right place to try out agile ways of working. But the research and development department, for example. In R&D, the division in companies responsible for step innovation (i.e. further development) as well as leap innovation (a completely new product), a stage or quality gate process has now largely established itself, in which various parameters are checked at certain breakpoints and non-performance leads to the end of the product idea. That doesn't sound so agile at first. However, people often overlook that especially at the beginning of a product development cycle, agile methods such as Srum or design thinking lead to the possibility of testing product ideas with significantly lower financial risk and a much stronger orientation towards potential customer needs. The latter is ultimately decisive for the success or failure of the product or service. Innovatin power can therefore be increased through agile working methods.
However, this also means that the "classic" stage-gate process requires modification at certain points in order to integrate this type of product (idea) development. And it means that organizations must face the challenges this way of working brings to leadership skills, cross-functional collaboration (including sharing resources and performance management), conflict resolution, stakeholder management and resilience.
We are happy to support you on this way!