{"id":7137,"date":"2025-11-26T12:11:10","date_gmt":"2025-11-26T11:11:10","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=7137"},"modified":"2026-02-14T19:36:51","modified_gmt":"2026-02-14T18:36:51","slug":"realism-instead-of-clairvoyance","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/realitaetsnaehe-statt-hellseherei\/","title":{"rendered":"Realism instead of clairvoyance"},"content":{"rendered":"

Execute complex software projects more effectively using agile methods.<\/h2>\n

Come on everyone, let's go agile today, and starting tomorrow our software projects will be purring like kittens! There are many indications that complex software projects can be carried out more effectively using agile methods. This is mainly because project teams confront their reality more quickly and decisively.<\/strong><\/p>\n

The transition to agile methodologies is initially an admission by project management and all other stakeholders involved in projects: "To be honest, we don't really have a complete overview!" This lack of overview is evident when we look from the project's present to its future. However, it's equally true when we look from the project's present to its past. While looking backward seems somewhat more realistic, it's distorted by all sorts of mechanisms of denial and idealization.<\/p>\n

If that's the case, perhaps we should pay a little more attention to the present. I don't mean that we shouldn't plan and organize projects, but rather that we should carry out realistic planning. What does realistic mean here? Realistic means agile.<\/p>\n

In broad terms, "agile" means the following: Our approach is based on the four values and twelve principles of the Agile Manifesto. Their implementation in the Scrum process framework is roughly outlined as follows:<\/p>\n

We set a project goal, define the essential quality characteristics, features, and risks, decide what needs to be done, and consider which factors we will use to verify goal achievement. In short, we give the project a rough framework, a general direction, and a clear objective. Then we decide what we can accomplish within a manageable timeframe to deliver a functional and tested interim result that we can present to the client.<\/p>\n

Each project team member now tackles approximately one task per day for a period of 2-4 weeks (sprint). The team monitors project progress daily in short meetings and meets every 2-4 weeks to determine which insights will be incorporated into further project development (retrospective) and what the next sprint (planning) will look like. After approximately 1-4 sprints, the result (release) is presented to the customer (results review). This is the basic process in an agile project.<\/p>\n

The ingenious principle behind this is that the project workflow is systematically interwoven with a communication process that fosters learning from experience. This ensures that project execution is monitored closely and promptly, allowing lessons to be drawn for future projects. This achieves precisely what is necessary when we realistically cannot predict the project's progress: we replace unrealistic long-term detailed planning with more short-term, detailed planning based on observations of the project's actual progress. We shift our focus from pointless attempts to predict the future to helpful observation of the project's realities. The great thing is that every stakeholder benefits from this learning process, especially the client, because they get exactly what they need.<\/p>\n

The project team benefits from the fact that this approach aligns with people's natural predispositions and needs:<\/p>\n