Knowledge Spiral
Constantly Evolving Knowledge
Agile practice frameworks do not arrive in ICT projects as a knowledge "thesis," but as an "antithesis" to the knowledge that Software Engineering had been developing.
We will begin by looking at what this means, and thereby gain the distance needed to see in perspective the reasons why ICT projects embraced agility at the end of the last century, and how it differs from process engineering: not from the standpoint of specific practices, but from the principles on which they are based, and in doing so understand the strengths and weaknesses of agility.
Gaining a view of the reasons and principles behind each methodology, beyond the specifics of any particular model, is key to making the leap from technical management to expert management. That is, from management based on applying practices to management based on applying one's own knowledge.
- Technical management: management based on applying models of practices and processes.
- Expert management: management based on the manager's tacit knowledge.
The dialectical pattern
Questioning knowledge sets its evolution in motion, and that evolution follows a dialectical pattern of thesis, antithesis, and synthesis.
Schematically, the dialectical pattern can be defined as the rhythm of progress that sets an antithesis against a prior conception, understood as the thesis. The antithesis reveals the problems and contradictions of the thesis, and from this confrontation a third moment emerges, called the synthesis: a resolution or a new understanding of the problem.
The strategy of tackling the challenges of software projects with process engineering was the first thesis in response to the "software crisis", and its problems and contradictions have been brought to light by its antithesis: agility.
In 1968, at the first software development conference held by NATO, the problems of software programming were analyzed and the term "software crisis" was coined to refer to them. The conclusion was the need to create a scientific discipline that would make it possible to apply a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software systems: Software Engineering was born.
The first strategy of Software Engineering (thesis) was based on two pillars:
- Process engineering: to apply the basic principle of quality: "the quality of the result depends on the quality of the processes used."
- Predictive management: to ensure compliance with schedules and budgets.
While this discipline evolved through different models (CMM-SW, ISO 9000, ISO 12207, SPICE...), doubts were arising in the software industry:
Is predictive planning appropriate for every project? Are the success criteria always meeting predetermined dates, costs, and functionality?
Projects began to emerge whose purpose was not to build a system fully defined in advance, but to bring something new to market as soon as possible and continuously evolve its value. It was also questioned whether software could be produced using industrial process patterns: the tacit knowledge of the person who does the work may matter more to the quality of the result than the know-how contributed by the process and the technology.
Dialectical spiral of knowledge
Professional knowledge evolves continuously because the reality in which it is applied is constantly changing, and also because improvement is always possible.
Putting new techniques, processes, or models into operation generates their own antitheses as their weaknesses, contradictions, and areas for improvement come to light, and the clash between the two leads to a synthesis, which will become a new thesis, whose use will in turn produce its antithesis, developing through this dialectical pattern a spiral of continuous evolution of knowledge.
In non-technical disciplines and in previous generations, the pace of progress along this dialectical spiral allowed professionals to perform throughout their entire careers with the knowledge acquired during their university degree. Today this is not possible, especially in the ICT sector.
There are no methods, practices, or working models that remain reliably helpful for long; there is evolving knowledge. This is why Scrum Manager does not define a fixed model, but rather up-to-date knowledge as the basis for management that is more expert than technical: based more on the manager's documented, expert judgement than on the application of practices or processes.
Common mistake
Treating agile frameworks as the definitive synthesis. The knowledge spiral suggests that agility is also a thesis that will generate its own antitheses. Believing that Scrum or Kanban are the final answer—rather than tools that will evolve—is repeating the same mistake made by the most rigid advocates of process models. Generative AI and its impact on development teams is already a significant antithesis to conventional agile practices.
References
- Orr, Ken. (2003). "CMM versus Agile Development: Religious wars and software development". Cutter Consortium, Executive Reports.
- Takeuchi, Hirotaka; Nonaka, Ikujiro. (2004). Hitotsubashi on Knowledge Management. Wiley.
- Turner, R.; Jain, A. (2002). "Agile Meets CMMI: Culture Clash or Common Cause?". XP/Agile Universe, pp. 153-165.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.