Context & starting point
I once said to a purist of the agile method: “No wonder the pyramids were never finished: back then they hadn’t mastered agile development and had no Scrum Master…”
That is, of course, provocative. But sometimes provocation is necessary to question a standpoint and encourage people to think for themselves instead of merely parroting some “modern nonsense”.
Terminology: artifacts vs. documents
Agile: today, documents and results are referred to as artifacts. The justification (study the method*) seems plausible. From my perspective, however, this shift is completely unnecessary: let us continue to call meeting minutes, specifications, FAQs, project progress reports, presentations, decision papers, etc. by their proper names.
*Agile: “artifact” has broad applicability. An artifact can take many different forms, such as user stories, product backlogs, sprint backlogs, burndown charts, or software increments. The term is broad enough to encompass all these different results.
Agility as a success factor
Yes, it is a fact that greater agility will lead to better project outcomes. This requires adapting to new insights, revising specifications that prove to be incorrect, reprioritizing, and leading the team efficiently.
But do I really have to throw everything overboard that has contributed to my success so far?
Rituals, roles & reality
If I quote the method or ask ChatGPT for a sprint plan and the responsibilities of the Scrum Master, it is often postulated that every morning about 15 minutes should be spent updating priorities, identifying impediments, maintaining motivation, etc.
When asked about the required skills of a Scrum Master, usually only soft skills are listed. Now imagine I am sitting in a sprint meeting as a 50‑year‑old and a young person is “performing” the Scrum rituals at the front. If that person cannot really tell me anything substantial, my motivation will quickly decline.
A pragmatic approach for mature organizations
My conviction: if a company employs experienced software developers who will work there until retirement (telecom providers, SAP, banks, insurance companies, etc.), then constructive ways must be found to “upgrade” classical methods with agility and align them with phased budget planning.
Otherwise, despite great effort, the key objective will not be achieved: making management (!) and teams more flexible.
Time pressure, planning & control
Development cycles are becoming ever shorter, and results must be delivered more quickly. Elements of agile methodology therefore need to be adopted constructively. At the same time, it is crucial to avoid introducing an uncontrollable form of development that no longer even allows established tools such as milestone trend analysis. Burndown charts are often not a true substitute, as agile planning too frequently disrupts the project budgets required.
From a business perspective, cost‑benefit planning must be set up and justified in a classical way in order to secure project budgets. Earned Value Management – i.e. development performance analyses already in early phases – must remain possible.
Conclusion
Being agile means weighing planned results against expected benefits while incorporating new insights, adjusting objectives appropriately, and thus cyclically updating project planning from both the customer’s and the company’s perspective – including the necessary budget and resource approvals.
Agile work also means, at management level, establishing proven methods such as maturity‑based leadership and organizing expertise in a way that is respected by employees.
Agility further requires constructively combining corporate or public‑sector planning horizons, the mindset of management and teams, and existing approaches.