There is a fundamental misunderstanding around agile. This misunderstanding begins with the title of the Manifesto for Agile Software Development. For too long, many considered software development to be the translation of specifications into code by interchangeable programmers completely disconnected from their customers and their products (and often reinforced by contracts). And this is exactly what many still understand by software development nowadays. Only in shorter cycles. Simply agile. But the authors of the manifesto, all passionate software developers, were concerned with something else. They tried to put software development back at the core of value creation and to eliminate all the waste around this core, all the heavy-weight processes and their manifestation in organizational structures. Their aim was to build software as a long-lived team really owning the product. And there must be no middlemen between team and customers with corresponding artifacts and handovers. Instead, business people and developers must work together on a daily basis to explore the market, the product and the solution space together.
The misunderstanding of this original intention of the Manifesto for Agile Software Development is reflected in many scrum adaptations in the role of the product owner. Where he or she should ideally see themselves as product managers or as the CEO of the product, he or she often only collects requirements and specifies them for the development team so that the developers can concentrate on development. You can call it agile, but it is not in line with the authors of the manifesto.
Because members of the project team stay in close touch with outside sources of information, they can respond quickly to changing market conditions. Team members engage in a continual process of trial and error to narrow down the number of alternatives that they must consider. They also acquire broad knowledge and diverse skills, which help them create a versatile team capable of solving an array of problems fast.
Hirotaka Takeuchi und Ikujiro Nonaka in The New New Product Development Game
This 1986 article by Takeuchi and Nonaka is considered to be the origin of Scrum. As the quote shows, even then, 15 years before the Manifesto for Agile Software Development, their research showed that a constant and intensive connection between the team and the outside world was needed in order to jointly gain new insights in a continuous process of trial and error. This joint exploration of the problem domain is one facet of what Tackeuchi and Nonaka called “multilearning”. The other facet of this is a learning culture in which everyone is constantly striving to share knowledge, broaden their skills and become experts in several different disciplines. This is exactly what makes interdisciplinary teams fast and effective.
A bad system will beat a good person every time.
W. Edwards Deming
In addition to a product owner as CEO of the product and product developers with skills in various disciplines, however, a third group is needed. It takes people who are able to analyze the dynamics of complex organizations and optimize them holistically from a systemic point of view, and who also have the power to do so. This systems thinking therefore should be the top priority of senior management. But this skill also should be mandatory for every Scrum-Master, who is — and this is the second big misunderstanding in many Scrum adaptations — not only facilitator and secretary of the Scrum events, but primarily analyzes and improves the productivity of the team as part of the surrounding organization from a systemic point of view.
Support This Site
Since 2010, a lot of work and passion has gone into my articles on leadership, agile, and more. My blog is and will remain free of advertising, but of course, there are still costs. If my work is worth more to you than a Like, you can support me via Ko-fi.