Kategorie-Archiv: IT-Governance

Conducting detailed contract negotiations has an invaluable advantage. The way of working in the project is worked through together, risk scenarios are discussed and how they would be managed. If this is omitted, an important phase of mutual scanning and getting to know each other before the actual project work starts is missing.

In any case, contract contents must cover the following topics:

• Goal and general conditions
• Description of results and road map
• Procedure model in general
• Tools used for
  – Collaboration and documentation
  – Requirements definition, development, test, operation
• Deliveries and services of the contractor
• Cooperation services of the client
• Remuneration for services
• Control, decisions, controlling
• Conflict settlement
• Rights and obligations of the contractual partners (before, during and after the project)
  – Duties of care, warning and information
  – warranty
  – Software maintenance and support
  – Operation and support.

Passing on risk often backfires

Since the success of a project depends to a large extent on the performance of the external service provider, the effort to pass on the risk of success to the latter through contracts is understandable. However, if we look at the financial performance of such a company, we see that it has a relatively low level of capitalization. IT service companies finance themselves through contribution margins from ongoing sales. Even large IT groups can only compensate for fee reductions to a limited extent. In any case, liability for financial losses due to lost customer profits exceeds their financial capacity. No large company would sign a contract containing such an obligation.

This is even more true for smaller IT service providers. If such a company were to take the risk of signing such a contract, bankruptcy would be the inevitable consequence if liability were to arise. In this case, the continuation of the project would be almost impossible.

For this reason, clients are reluctant to apply the full rigor of contracts even in the case of serious performance deficiencies. Tough contracts won at the beginning at the expense of the contractor often impair the climate of cooperation, and in serious cases they regularly prove to be toothless. This makes it clear that the real damage resulting from a failed IT project is always much greater for the client than for the contractor, regardless of how the contract texts present it.

Lawyers know IT projects from a specific perspective

The drafting of contracts is a matter for lawyers. However, there is a fundamental problem here. Lawyers only know projects from contract negotiations and rarely have anything to do with normal project execution. Only projects that fail and perhaps even end up in court end up back with the lawyers. In such a situation, when continuation of the project is already ruled out anyway, „hard“ contract provisions are worth a lot. It is therefore only natural that lawyers look for hard hedging formulations, for example penalties and liability provisions. These provisions don’t matter in a project that goes reasonably well. Nor do they interfere.

If the only thing left to do in a failed project is to limit the financial damage, depending on the creditworthiness of the contractor, at least a little damage mitigation can be gained from such clauses. A legal dispute is shied away from, because the question of fault can only be clarified with a series of costly, time-consuming expert opinions whose statements are unpredictable. Therefore, such disputes usually end with an out-of-court settlement. The damage to the client is regularly far higher than can be gained in practice through penalties and liability claims. But the tougher the contractual clauses are formulated in favor of the client, the better the cards are in settlement negotiations.

The impact of contracts on project progress

Let us now turn to the effects of a contract on the „normal“ course of a project. The tougher the contractual provisions are and the more threatening they are for the contractor, the more the project managers, lawyers and claim managers at the contractor’s end are instructed by management to do everything in their power to avert threatening scenarios. As a precaution, they naturally try to compensate for concessions that had to be made during contract negotiations. This plan has a good chance of succeeding. There is no IT project in which the specifications and framework conditions given at the start of the project remain constant until the end of the project.

The more precisely everything was specified during the contract negotiations, the higher the probability that something will happen on the part of the customer that is not in accordance with the contract provisions. A classic example of this is the client’s cooperation. These are always necessary, the larger the project, the more so. The more pressure is exerted on the contractor during contract negotiations, the more the contractor will insist that the client’s cooperation services also be precisely defined. As the client, this is difficult to refuse. As soon as the first item in the customer’s list of obligations is not fulfilled, a domino effect is triggered.

The balance of power reverses in the course of an IT project

If, up to the time the order is placed and even in the first few months of the project, the client is the courted customer whose decisions count, then as the project progresses, the client develops a dependency on the employees of the external service provider who are now familiar with the subject matter. Eventually, the point is reached where the client’s greatest concern is that these key people may no longer be available. While in other industries, for example in the construction industry, the replaceability of service providers is high, this is not the case with IT projects.

After a relatively short time, the external employees are more familiar with the details than the client’s employees. Firstly, because they are usually highly qualified and highly motivated people, and secondly, because they are not caught up in the day-to-day business. They therefore acquire a solid knowledge of the requirements very quickly. Due to their routine and focus, they quickly become familiar with the subject matter and soon know more about it than an average clerk.

The client is therefore dependent on the contractor not withdrawing its key personnel. These people, who are all the more important as know-how carriers the less cooperation the customer has accepted, ultimately become aces in the power game between the contracting parties. Once this spiral is set in motion, the big end usually follows on its heels. New contract negotiations, now under significantly worse conditions for the client, who has his back to the wall, regulate the continuation of the project. After all, the project can now be completed, it will be finished later than planned and it will also be more expensive. It is not obvious that it was precisely the „great“ contract provisions at the beginning that made the problems significantly worse. Nor does anyone want to hear it at this point. It is also reasonable not to discuss the past now.

How should contracts be designed?

So when the parties involved draw up contracts, they should be oriented toward productive cooperation and regulate their modalities. As unsatisfactory as it may be if no fixed price can be agreed upon, the agreement of a procedure for price determination and for dealing with identified additional expenses is the more reasonable approach.

There are IT projects for which a fixed price agreement is possible and makes sense. This applies to the operation of a data center, the installation of hardware and standard software, or the handling of help lines. Penalties can also be defined there in such a way that they have a controlling effect on the contractor’s performance. It is only dangerous to apply an effective tool to the wrong object.

Contracts must enable constructive and productive cooperation. If a project is going well, then at best you look at the contract in the sense of „What have we agreed on this? – Aha, then we’ll do it like this!“

It is more beneficial for the client to rely on the economic interest of the contractor in a successful project than on penalties and liabilities in the event of failure. However, this requires understanding how an agile project works and acting accordingly.

Agile projects – the nightmare of classic contract designers

In general, the Standish Group’s figures prove that large IT projects in particular have a significantly better chance of success with an agile process model. While the tools of a classic work contract can be assumed to be universally known, the contract design for agile projects is not yet common knowledge. If a philosophy of project management is stipulated in project orders or contracts that contradicts an agile approach, the contractual partners either end up in a contract-free space or they constantly collide with contractual provisions that do not fit the actual approach.

In general, agile software development is based on effort allocation, since a fixed work charge cannot be defined due to the lack of a detailed description of the results. The resulting vagueness is regularly overestimated by all participants: Everyone knows from their own experience that fixed prices are regularly undermined by change requests. Therefore, an effort estimation with admitted bandwidth as well as a project control based on it by burn-down charts is the more honest and de facto also more effective method. However, one must be able to face the uncertainty made visible here, which not all clients are willing and able to do. This applies all the more if the implementation is not carried out by the company’s own IT department, but by an external company.

The central challenge can be formulated like this: Professional project management replaces detailed definition of results. Deviations are thus detected earlier than in classic projects. For this to work, suitable processes must be defined (also contractually) and lived. Agile projects require more project management skills, especially on the part of the customer.

Agile projects can therefore only succeed if there is active and knowledgeable participation by the customer. In the case of an external assignment, this applies not only to the user areas („business“), but also to the IT department of the client. Compared to a waterfall model, these end-to-end involvement services appear to be an additional expense. Whether this saving is lost again in later project phases due to rework is not known at the beginning. My own experience and that of all agile project managers shows that the actual total effort of well-managed agile projects is significantly lower than that of a classic project according to a waterfall model. However, the effort is distributed differently, namely fairly evenly over the entire duration. I have commented in more detail on questions of effort in Chapter 4.

The same applies: Agile procedures require trusting cooperation. For this, the willingness and ability for interdisciplinary work and social skills must be available among all participants.

What is the truly decisive success factor for agile IT projects?

In my experience, trust in the appropriateness of the realization partner’s efforts is a crucial success factor. Negotiating the waiver of features in order to stay within budget and the final deadline only works if the contractor’s estimated realization efforts are seen by the client as reasonable and understandable. Effort estimates that are regularly perceived as excessive may be due to architectural deficiencies and therefore may in fact be reasonable. In practice, however, these are usually interpreted as an indicator of unfair pricing by the contractor, leading to conflicts, mutual accusations and recriminations. These can only be resolved, if at all, by external expertise or – the more common case – resignation on the part of the client in view of the hopelessness of parting ways with the current contractor.

Contracts for work no longer work – a new paradigm is needed

The contract model must depart from the ideal of the work contract (transactional contract type: definition of a work to be created at a price fixed in advance) and implement „relational contracts“. Such contracts regulate the collaboration. Part of the agreements is the procedure for defining the desired result and the associated financial transactions.

A team of authors led by Nobel laureate Oliver Hart described this paradigm shift this way in the Harvard Business Review (September/October 2019):

• Traditional sales contracts do not work in complex strategic relationships where parties are highly interdependent, future events cannot be predicted, and flexibility and trust are necessary. Instead of fostering the collaborative relationships needed to address these challenges, traditional contracts undermine them.
• A relational contract lays the groundwork for trust, defines mutual goals, and establishes governance structures to harmonize the parties‘ expectations and interests over time.
• Relational contracts will never fully replace traditional transactional contracts, nor should they. But the process for agreeing a relational contract should be part of the contracting toolkit to govern highly complex relationships that require collaboration and flexibility.

Today, IT projects of a certain size fulfill exactly the requirements mentioned by Hart et al. It is therefore not surprising that they so often fail due to the application of traditional contract models. Karl Kraus once said that psychoanalysis is the disease it thinks it cures. I think something like that can rightly be said about many contracts that are supposed to ensure the success of an IT project.

Deutsche Version hier/German Version here.

To deal with complex situations (and projects are always complex) we need models that focus our attention on the relevant aspects of the situation we have to deal with. Models are always simplifications, otherwise they would be of no use, but it is important that the simplification is appropriate in terms of the objectives.

An important model is the distinction between objectives, constraints and measures.

Objectives are those characteristics that, for example, the project outcome should have when the project has been successfully completed. This typically involves the so-called magic triangle of project management, namely result, deadline and effort.

Measures are those options for action that the project manager, a certain team member, or the project client can decide on or actually decides on.

Constraints are those circumstances which either cannot or should not be influenced in the given situation, but which are important for the achievement of the set goals. They therefore influence the effectiveness of measures.

To clarify the difference between goals and measures, one could say:

Objectives are statements about which problems are to be solved.
Measures are possible solutions to these problems.
This distinction is not universal, however, but is different for each person or organizational unit; it is obvious that the project client has options for action that become constraints for the project manager. Bringing about such action is a goal for the project manager, which he or she seeks to bring about as an action, e.g. through information and arguments.

Do not confuse goals with constraints or action points

In every situation, and especially in a critical project situation, one should clearly distinguish between what is the goal (problem) and what is the measure (solution) considered appropriate. If one solution does not bring the hoped-for result, one will have to look for other solutions, but cannot exchange the problem for another.
Constraints are thus less variable compared to measures: the constraints because they are beyond the influence of the acting person; the goals because they contain the actual purpose of the action (their „ultima ratio“). Measures, on the other hand, are highly interchangeable. If there are different ways of achieving a goal, one will choose the one that leads to the goal most safely and with the least effort under the given conditions. Mixing objectives and measures, on the other hand, leads to measures becoming an end in themselves. For example, deadlines are often set for a project without defining suitable measures that make it possible to meet the deadline under the given conditions.

It is also a permissible measure to postpone the deadline, increase the budget and reduce the result expectations, it only has to be clear who can recognize these measures as sensible or necessary, but can only actually implement them by influencing others (in this case probably the project client). The project manager’s measure in this case is therefore to push through such a measure in the project committees responsible for it.

This also shows that a factor that was previously considered a constraints (result, deadline, budget) can become the object of a measure that has the goal of changing this constraint.

This probably sounds rather theoretical, but in practice it is of decisive importance for success. Only if I can clearly see in every situation what my goals are, what my constraints are and what my options for action (i.e. possible measures) are, will I manage to quickly find out what I can do now to lead a project to success.

IT-Governance ist ein strategischer Ansatz, der dazu dient, die IT-Ressourcen eines Unternehmens sinnvoll zu nutzen. Dabei geht es nicht nur darum, die IT-Systeme zu verwalten, sondern auch darum, die Unternehmensführung in die richtige Richtung zu lenken. IT-Governance ist daher eine der zentralen Herausforderungen für Unternehmen, um Wettbewerbsfähigkeit und Erfolg zu erzielen.

1. Was ist IT-Governance?

IT-Governance ist nicht nur für die IT von entscheidender Bedeutung, sondern stellt auch eine zentrale Herausforderung für die gesamte Organisation dar. IT-Governance beinhaltet die Festlegung von Verantwortlichkeiten, Richtlinien und Prozessen, um die IT-Strategie des Unternehmens zu entwickeln und durchzusetzen. Es hilft, Risiken und Chancen zu verwalten, aber es geht auch darum, dass alle Beteiligten an der IT-Strategie des Unternehmens beteiligt sind und verantwortlich sind. Eine gute IT-Governance stellt sicher, dass die Unternehmensstrategie mit der IT-Strategie in Einklang gebracht wird und dass alle Beteiligten dieselben Ziele verfolgen. IT-Governance ist daher ein wesentlicher Bestandteil des Unternehmenserfolgs und eine Grundvoraussetzung für eine erfolgreiche Umsetzung der Unternehmensziele.

2. Warum ist IT-Governance eine zentrale Herausforderung?

IT-Governance ist eine zentrale Herausforderung für Unternehmen, da es ein wesentlicher Bestandteil des unternehmerischen Erfolgs ist. Unabhängig davon, ob Ihr Unternehmen ein großes oder kleines Unternehmen ist, ein einzelnes Unternehmen oder ein Unternehmensnetzwerk, IT-Governance ist eine Schlüsselfunktion, die sicherstellen soll, dass die IT-Investitionen effizient und effektiv sind. Eine gute IT-Governance-Strategie ist für die Compliance, die Sicherheit und die Skalierbarkeit von entscheidender Bedeutung.
Es ist wichtig zu beachten, dass IT-Governance nicht nur für die IT eine zentrale Herausforderung ist, sondern auch für das gesamte Unternehmen. Unternehmen müssen die Kontrolle über die IT-Ressourcen haben, um effektiv zu sein und das Geschäft voranzutreiben. Wenn die IT nicht effizient genutzt wird, sinken Produktivität und Effizienz. Die IT-Governance muss strategisch, technisch und organisatorisch sein und verhindert, dass das Unternehmen in eine Richtung läuft, die nicht den Zielen und Werten des Unternehmens entspricht.
Es ist wichtig, dass die IT-Governance-Strategie des Unternehmens regelmäßig überprüft und den aktuellen technischen und organisatorischen Anforderungen angepasst wird. Nur so kann gewährleistet werden, dass die IT-Investitionen effizient und nachhaltig sind. Zudem müssen Unternehmen sicherstellen, dass die IT-Governance-Strategie einfach und transparent ist, damit die Mitarbeiter sie verstehen und umsetzen können. Durch die Implementierung einer erfolgreichen IT-Governance-Strategie kann ein Unternehmen die Unternehmensleistung und den Unternehmenserfolg nachhaltig verbessern.

3. Welche Rolle spielt die IT in Unternehmen heutzutage?

Heutzutage ist die IT für Unternehmen zu einem zentralen Bestandteil der Geschäftstätigkeit geworden. Nicht nur die IT-Abteilungen sind dafür verantwortlich, dass die Unternehmen die technologischen Entwicklungen im Blick behalten, sondern auch andere Abteilungen müssen in der Lage sein, die IT-Lösungen effektiv zu nutzen. Daher ist IT-Governance die zentrale Herausforderung, um eine nachhaltige IT-Strategie zu entwickeln, die auf die Geschäftsanforderungen angepasst ist. Ein effektives IT-Governance-System kann Unternehmen helfen, sicherzustellen, dass ihre IT-Systeme effizient, rechtzeitig und wirtschaftlich betrieben werden. Es hilft dabei, die IT-Ressourcen auf einer strategischen Ebene zu planen, zu verwalten und zu steuern, um die Geschäftsziele zu erreichen. Außerdem kann die IT-Governance auch dabei helfen, die Risiken zu minimieren, die sich aus der Nutzung neuer Technologien ergeben. Kurz gesagt, der richtige Einsatz und die ordnungsgemäße Nutzung von IT-Governance-Tools können Unternehmen dabei helfen, über die täglichen Herausforderungen hinauszugehen.

4. Wie kann man das Potenzial der IT effektiv nutzen?

Um das Potenzial der IT effektiv zu nutzen, ist IT-Governance nicht nur für die IT, sondern für das gesamte Unternehmen von entscheidender Bedeutung. Es ist wichtig, dass alle Abteilungen des Unternehmens die IT-Governance-Prinzipien verstehen und anwenden. Nur so können sie die Technologie zur Unterstützung ihrer jeweiligen Ziele nutzen. Es ist auch wichtig, dass die IT-Governance-Prozesse regelmäßig überprüft und an die sich ändernden Bedürfnisse des Unternehmens angepasst werden. Auf diese Weise können alle Abteilungen des Unternehmens sicherstellen, dass die IT-Ressourcen sinnvoll und effizient eingesetzt werden und das Unternehmen das bestmögliche Ergebnis erzielt. Auf diese Weise können die Unternehmen auch ihre IT-Investitionen effektiv nutzen und gleichzeitig das Risiko von Fehlinvestitionen verringern.

5. Fazit

Es ist offensichtlich, dass IT-Governance nicht nur für die IT eine zentrale Herausforderung darstellt, sondern auch für die gesamte Organisation. Es ist wichtig, dass die IT-Governance-Richtlinien in den gesamten Unternehmensbetrieb einbezogen werden und dass sie dem Geschäftsbetrieb unterstützend zur Seite stehen. Eine gute IT-Governance kann helfen, ein Unternehmen zu stärken, indem sie die Sicherheit und Effizienz des Unternehmens erhöht. Sie kann dazu beitragen, die Kosten zu senken, ein besseres Risikomanagement zu betreiben und das Unternehmen vor unerwarteten Ausfällen zu schützen. Eine gute IT-Governance-Struktur kann auch dazu beitragen, eine klarere Sicht auf die IT-Anforderungen des Unternehmens zu erhalten, die für eine nahtlose Kommunikation und Zusammenarbeit erforderlich ist. Kurz gesagt, IT-Governance kann zu einem effizienteren und sichereren Geschäftsbetrieb beitragen.

Mehr zum Thema:

COBIT – der Standard der ISACA

Warum nicht auch Wikipedia konsultieren?

Speziell zu IT-Governance in der öffentlichen Verwaltung ein Buch

Und an dieser Stelle doch auch der bescheidene Hinweis auf mein Buch 😉

Ein Vortrag von mir zum Thema

BTW: German version here/Deutsche Version hier.

Again and again and in different contexts W. Ross Ashby’s „Law of Necessary Diversity“ is quoted and I have never heard a contradiction. I read Ashby’s book „Introduction to Cybernetics“ a long time ago and learned a lot from it. The law so much quoted (chapter 11/6), of course, impressed and convinced me very much at that time. But soon I had my problems with the conclusions drawn from it and they became bigger and bigger.
Why is this important and, above all, what does it have to do with our concrete challenges in managing projects? I think that the conclusions are decidedly misleading and that it puts the success of projects at risk. So it’s not just my own personal problem of understanding, there are serious practical consequences at stake.

What did Ashby actually say?

Let’s start at the source. Ashby refers to game theory, and he describes the situation of two players, R and D. When D makes a play, R must decide which play to counter with. The number of possible outcomes of the game now depends on how large the number of possible moves of D is and how far R manages to reduce this variety so that ideally only the outcomes in which he is the winner occur. If there is always only one possible outcome, no matter what D does, where would the variety of outcomes be reduced to its absolute minimum, namely 1. If R has two different moves available, then at best he can reduce the variety of outcomes to half the possibilities. The law reads, „Thus, if the variety in outcomes is to be reduced to a fixed number or to a fixed fraction of D’s variety, then R’s variety must increase at least to the necessary minimum. Only diversity in R’s moves can lower diversity in outcomes.“ And a few paragraphs further on the sentence that everyone quotes: „Only diversity can destroy diversity“.

That the last sentence cannot be true in this way should be immediately obvious. Let’s take a fly as an example, which flies a complicated course. All it takes is a well-aimed stroke with the fly’s flap (an action with very little complexity) to destroy the fly’s diversity of movement once and for all. Some will classify this example as harebrained, but it brings us to the crucial point. If we wanted to reduce the diversity of the fly’s positions relative to us, we would have to be just as mobile as the fly and follow on its heels. Thus, if one acts within the same set of rules as the opponent (to abstract from the unfortunate fly), then Ashby’s Law applies. But if a player switches paradigms, it loses its validity.

The law of requisite diversity applies when everyone is operating within the same set of goals and rules. The goal of the game is also important. Let’s take a real game like tennis or soccer. In tennis there is always a winner and a loser, in soccer there can be a draw. If one accepts maximizing the number of wins and minimizing the number of losses as the goal, the variety of outcomes is drastically reduced. Success in soccer is possible with a complex short passing game (Tiki-Taka, we remember the successes of FC Barcelona) as well as with a defensive strategy (Catenaccio, with which Inter Milan was once very successful). Tiki-Taka is more likely to be associated with the attribute „diversity“, only this diversity can be „destroyed“ with a much less diverse style of play, as has been empirically observed for some time.

Enough with analogies

But now enough of analogies, let’s turn to our field of action. If one were to interpret Ashby’s law as all business authors known to me do, then a complex project characterized by diversity of possible outcomes would have to be managed by a correspondingly complex project organization. Let’s stay briefly in Ashby’s terminology: A complex project is characterized by a variety of influencing factors and results (including all relevant intermediate results). This is countered by a complex project organization (matrix is always a good idea there), a large number of precisely defined work packages, detailed schedules with milestones, dependency matrices, risk catalogs, controlling reports, etc., etc. If deviations from the plan are detected, they are responded to with even more complex structures and processes, because: Complexity can only be mastered with complexity (if we replace the misleading word destroy).

But: This is exactly the trap that Paul Watzlawick so aptly described in his „Guide to Unhappiness“: „More of the same“. He sees this as „one of the most successful and effective catastrophe recipes that has developed on our planet over millions of years and has led to the extinction of entire species (p. 28)“.

You can and must reduce complexity

I have experienced it so many times: If deadlines are not met, scheduling is refined and controlling is expanded. Once I had to step in at short notice as a crisis manager and report twice a week on the adherence to about 50 detailed deadlines, leaving correspondingly less time to work. Only after a few weeks did I manage to reduce this to once a week, and after some interim successes we were able to switch to two-week iterations, the results of which were reported. That’s also how we got to success. So we responded to the diversity of project challenges (many deadlines did not hold or could not be guaranteed) by reducing complexity. Luhmann has argued at length that it is precisely the reduction of complexity that is the crucial cultural achievement. Given the overwhelming volume of his publications, I would like to refer here to a key work where he presents trust as a mechanism for reducing social complexity. For our context, for example, trust in the competence of the project team allows a significant reduction of control mechanisms and vice versa.

Agile project management is simple yet effective

If we look at agile process models, it is noticeable that they are organized in a significantly less complex way than classically managed projects. The fixed timing of iterations, the breaking down of the entire workload to a backlog list of user stories, the abandonment of success controls by announcing degrees of completion (instead, the delivery of functioning software at the end of each iteration serves as the only relevant measure of progress) are examples of radical simplifications. However, agile process models were created to handle projects that are characterized by high complexity (moving target). Their success proves them right. The success rate of large software projects is significantly higher when using agile methods than with „classic“ process models, the more so the larger (and thus probably also more complex) the project. This is the clear finding of the Standish Group.
Summarized: You can react to the complexity of the task by increasing the complexity of the project organization. However, this is not a good idea. It is better to meet this complexity with simple but effective structures. This can be Scrum as a particularly uncomplex, because strictly predefined execution method. It can be XP, with a particularly simple intervention: let users and technicians work together directly. It can also be Lean, Kanban or DSDM. I gave an overview of these in another blog post, with a list of links.

What does this mean for practice

So is Ashby’s law wrong? No! Ashby’s law is just like the laws of physics. For example, the law of falling states that a feather and a lead ball fall to the ground at the same rate. In everyday life we cannot observe this phenomenon, because the law is valid in such a way only in the absolute vacuum. Ashby’s law is valid only within a closed control system with fixed target variables. This is overlooked in the common conclusions drawn for practice. This in turn leads to negative consequences. Keep it simple is also too undifferentiated a recommendation; the important thing is to find a suitable simplification. Agile process models are an example of this.

BTW: German version here/Deutsche Version hier.

The world of software development changed strongly

As long as it was (and often still is) costly to change a screen or list layout, these specifications had to be fixed as early as possible in the project. If, on the other hand, it is easy to insert even new fields into the database even in late project phases, less effort has to be made with these specifications. The user no longer has to create detailed specifications and then sign them, so that he can only make change requests under penalty of considerable additional costs. This still happens, but it is more of an obedience test than a real necessity.

But if things are a bit more relaxed on these points, so to speak, where else can you do without hard work and commitment in early project phases? Do we still need an architecture concept, a data model, use cases, etc.? Let’s just work again according to the motto BID (brain into device), as it was common in the early days of IT. Back then software development was done by developers for developers and no one was there to make demands on the result without understanding and mastering the technology? The only thing that disturbs is the user, that’s probably how many developers silently think.

Spontaneous or structured?

In view of the new development tools and platforms, can the user perhaps make himself comfortable at all, be content with information about his requirements in free prose as well as critical comments on the prototypes presented to him, wait for the software developers to deliver the information system he has dreamed of sooner or later?
Or, conversely, do the software developers just have to give the user a tool, explain it to him, let him work with it for some time, and finally assemble the delivered parts into a user-friendly, technically optimal, and cost-effective information system?

Of course we all know that both extremes are not feasible and of course there is no one who seriously advocates such a scenario. But still, some things are in flux and there is uncertainty among all parties involved.

I think that even in agile projects some obligations remain, these affect all participants. Being flexible is not the same as being superficial, erratic and non-committal.

The duties of the users in agile projects are considerable

The users (meaning both the management and the users in the narrower sense) must develop a clear idea of what contributions an IT system should make to the success of the company as a whole and to the improvement of the addressed business processes in particular. An iterative approach favors the development of creative solutions, since strategic, organizational and technical imagination can interact better than within the framework of a classic, strictly phase-oriented approach based on the waterfall model. But there comes a time when you have to commit yourself, and that always means giving up something, at least for the time being.

It is one of the standing rules of IT strategy that the organizational issues must first be clarified before the IT application makes sense. And it is just as true that in practice, attempts are regularly made to get a grip on organizational problems via IT. If a rule is so often ignored, there is a suspicion that it is either wrong or at least unworkable in practice; according to a pragmatic notion of correctness, however, it is thus also wrong in the second case.

Organization and IT systems can of course be optimized separately and one after the other. However, there is no doubt in my mind that only a suboptimum is regularly achieved: If the user knew what possibilities IT could offer him, he would perhaps organize himself differently. If the software developer knew which requirements the user had not named because he did not consider them feasible or could not imagine them, he would solve some things differently.

Everything is possible, nothing is fixed?

If you basically wanted to optimize both subsystems at the same time, you would quickly exceed the limits of manageable complexity, the agility of the organization and the patience of the users. This is precisely where the possibility provided by modern development platforms to stimulate the user’s imagination in early phases with rapidly developable prototypes is extremely useful. However, only the user can make the final decision as to which type of IT support is worthwhile for which tasks and with which degree of convenience.

Particularly if one deviates from a strictly phase-oriented process model, there is a danger that the precision of project planning will be reduced and project management will become lax. However, it is one of the paradoxes we have learned from participatory organizational design projects that not only with the increasing number of participants but also with the increasing degree of participation, the tighter the project management has to be. The more creative leeway you give the participants, the more often changes occur that have repercussions in other areas. Interface, communication and stakeholder management must therefore be performed with the utmost professionalism in agile projects, significantly more so than in projects based on a more or less strict waterfall model. Milestone dates must be coordinated and the regular, proactive exchange of information must be ensured.

Written project assignments that are understood and recognized by all participants, a clearly defined project organization, and in particular project managers with sufficient decision-making authority and resources are some of the other elements that have always characterized good project management and are even more important under the more complex conditions of the agile approach.

It is the non-delegable duty of the user, especially the management, to take overall responsibility for the success and thus the overall project management.

Change is important and possible – but what kind of change?

Agile process models allow IT systems to change in the course of their development. Watzlawick et al. distinguish between two forms of change: „one takes place within a particular system, which itself remains unchanged, while the occurrence of the other changes the system itself“ (p. 29). They speak of first-order change and second-order change, respectively.

If we consider an IT application as a system of functions and data that are combined into applications and implemented on specific hardware and operating system platforms, agile process models facilitate first-order change. However, if it is necessary to change the character of the system as a whole, agile process models only marginally facilitate this. Agility therefore does not spare us the elaboration of a well thought-out IT architecture, but they do decisively facilitate first-order change, namely system optimization within the framework of a given architecture.

Good architecture does not come from occasional architects!

Software development without programmers? Software development by the users? Maybe, but it also depends on whom you call programmers and whom you call users. And it certainly also depends on how complex a software system is. If we agree that someone who writes macros in Excel, for example, or performs similar tasks in other systems is not a programmer, we cannot agree with the promises quoted above. If we make an analogy to construction, we see that in the age of prefabricated houses, very many builders no longer need an architect. However, prefabricated houses have been designed by architects and the more or less high quality of the design is recognized by anyone who wants to adapt a prefabricated house to his individual needs. If we go one step further to urban planning, we can clearly see the limits of self-planning in the urban planning stains of some communities. So if we want to avoid a „shake-up“ of the IT landscape (i.e., a collection of isolated solutions with complex interfaces), we cannot avoid having professionals supervise and sometimes guide the users, even in the age of Scrum and XP.

Not to forget: There are also duties of IT in agile projects.

So the duties of the user end where the overall architecture and the optimal technical design of the IT system are concerned, but they apply all the more when it comes to clarifying the strategic, economic and organizational prerequisites and framework conditions of the IT deployment. But this is where the success of the IT deployment is largely decided, regardless of whether we work agile or not.

The successful interaction of many stakeholders does not work without stable structures and disciplined collaboration. Flexibility requires a lot of work, and not just when it comes to yoga.

Der effektive Einsatz der Informationstechnologie ist zu einem unverzichtbaren und integralen Bestandteil des Business-Managements geworden. IT-Projekte sind die Trägerraketen für die Weiterentwicklung des Geschäftsmodells und der Geschäftsprozesse. Allzu oft scheitern diese oder bringen nicht die erhofften Ergebnisse. Manchmal liegt es an einer unausgereiften Technologie, aber meist ist es der menschliche Faktor, der über Erfolg und Misserfolg entscheidet. 

Bedeutung der Kommunikation in der IT-Governance

Die Kommunikation spielt eine zentrale Rolle in der IT-Governance. Sie ermöglicht eine klare und verständliche Vermittlung von Informationen, die für den Erfolg eines IT-Projekts von entscheidender Bedeutung sind. Eine transparente Kommunikation sorgt dafür, dass alle Beteiligten jederzeit über den aktuellen Stand des Projekts informiert sind und sich aktiv einbringen können.

Kommunikationsstrategien in der IT-Governance

Eine effektive Kommunikation in der IT-Governance erfordert eine gezielte Strategie. Es ist wichtig, die Bedürfnisse und Erwartungen der Projektbeteiligten zu verstehen und entsprechend zu kommunizieren. Dabei können verschiedene Kommunikationsstrategien eingesetzt werden:

Regelmäßige Meetings und Statusupdates

Regelmäßige Meetings und Statusupdates sind eine effektive Möglichkeit, um alle Projektbeteiligten auf dem Laufenden zu halten und Missverständnisse zu vermeiden.

Klare Zielvorgaben

Klare Zielvorgaben erleichtern die Kommunikation und sorgen dafür, dass alle Projektbeteiligten auf das gleiche Ziel hinarbeiten.

Offene Kommunikation

Offene Kommunikation sorgt dafür, dass Konflikte frühzeitig erkannt und gelöst werden können. Durch eine offene Kommunikation können zudem innovative Ideen und Lösungen gefunden werden.

Auswahl der richtigen Kommunikationsstrategie

Die Auswahl der richtigen Kommunikationsstrategie hängt von verschiedenen Faktoren ab. Es ist wichtig, die Vor- und Nachteile der verschiedenen Strategien zu kennen und je nach Bedarf zu nutzen. Eine erfolgreiche Kommunikation ist dabei unerlässlich für den Erfolg eines jeden IT-Projekts.

Kommunikationskanäle in der IT-Governance

Die Wahl der richtigen Kommunikationskanäle ist entscheidend für den Erfolg der IT-Governance. Es gibt verschiedene Arten von Kommunikationskanälen, die je nach Projekt und Zielgruppe eingesetzt werden können.

E-Mail und Telefon

E-Mail und Telefon sind die klassischen Kommunikationskanäle, die bei nahezu jedem Projekt eingesetzt werden. Sie sind schnell, einfach und praktisch. Doch sie können auch schnell unübersichtlich werden und es besteht die Gefahr, dass wichtige Informationen untergehen. Zudem können sie schnell missverstanden werden, da Emotionen und Körpersprache nicht transportiert werden können.

Chat und Instant Messaging

Chat- und Instant-Messaging-Systeme ermöglichen es Projektmitgliedern, in Echtzeit zu kommunizieren und schnell auf Fragen und Probleme zu reagieren. Sie sind besonders nützlich für virtuelle Teams, die räumlich getrennt arbeiten. Allerdings sollten sie nicht als Ersatz für persönliche Gespräche betrachtet werden.

Video- und Webkonferenzen

Video- und Webkonferenzen bieten die Möglichkeit, sich virtuell zu treffen und in Echtzeit zu kommunizieren. Sie sind besonders nützlich für Teams, die geographisch verteilt sind und nicht in der Lage sind, persönlich zu treffen. Video- und Webkonferenzen können jedoch teuer sein und erfordern eine zuverlässige Internetverbindung.

Projektmanagement-Software

Projektmanagement-Software ermöglicht es Projektmitgliedern, Informationen und Dokumente zu teilen, Aufgaben zu delegieren und den Fortschritt des Projekts zu verfolgen. Sie sind besonders nützlich für komplexe Projekte mit vielen Aufgaben und Teammitgliedern.

Soziale Medien

Soziale Medien wie Facebook, Twitter und LinkedIn können für die Kommunikation innerhalb eines IT-Projekts genutzt werden. Sie ermöglichen es Projektmitgliedern, schnell und einfach Informationen zu teilen und Feedback zu erhalten. Soziale Medien sollten jedoch nicht als Ersatz für andere Kommunikationskanäle betrachtet werden.

Schlussfolgerung

Die effektive Kommunikation ist ein entscheidender Faktor für den Erfolg der IT-Governance. Sie ermöglicht eine klare Definition von Rollen und Verantwortlichkeiten, fördert die Zusammenarbeit und stellt sicher, dass alle Beteiligten auf dem gleichen Stand sind. Durch die Wahl der richtigen Kommunikationsstrategien und -kanäle kann die Kommunikation in IT-Projekten erheblich verbessert werden. Dies führt nicht nur zu einem erfolgreichen Projektabschluss, sondern trägt auch zu einer höheren Effizienz und Produktivität im Unternehmen bei.

Agiles Projektmanagement ist eine Methode, die sich auf Flexibilität und kontinuierliche Verbesserung konzentriert. Dieses Konzept wurde ursprünglich in der Softwareentwicklung eingeführt, um besser auf sich ändernde Anforderungen reagieren zu können. Im Laufe der Jahre hat sich das agile Vorgehen jedoch auch in anderen Bereichen durchgesetzt.

Was ist Agiles Projektmanagement?

Agiles Projektmanagement ist eine Methode, die sich auf die schnelle und effiziente Reaktion auf Änderungen konzentriert. Im Gegensatz zu traditionellen Projektmanagementmethoden, die oft starre Prozesse und Strukturen aufweisen, ist die agile Methode flexibel und passt sich an die sich wandelnden Bedürfnisse des Projekts an. 

Das Bild zu Beginn dieses Beitrages zeigt die Elemente eines Projektes und ist damit ein Rahmen, in dem man die Unterschiede zwischen agilem und klassischem Projektmanagement erkennen kann. Im Kern ändert agiles Projektmanagement die Prozesse zur Einsatzsteuerung der Ressourcen. Dabei kommt allerdings dem „menschlichen Faktor“ besondere Bedeutung zu, ein „agiles Mindset“ ist notwendig, damit diese geänderten Prozesse auch wirklich zum Erfolg führen. 

Die Geschichte des Agilen Projektmanagements

Das Konzept des agilen Projektmanagements entstand in den 90er Jahren im Bereich der Softwareentwicklung. Entwickler waren mit den unflexiblen Prozessen unzufrieden und suchten nach einer leichtgewichtigeren und flexibleren Methode. Dies führte zur Schaffung neuer Prozesse wie Scrum. Trotz dieser Fortschritte gab es bis 2001 noch keinen einheitlichen Begriff für diese neuen Entwicklungsmethoden. Daher wurde der Begriff „Agiles Projektmanagement“ geprägt, um diese Art der Entwicklung zu beschreiben, die sich auf Flexibilität und ständige Anpassung konzentriert.

Das Agile Manifest

Das Agile Manifest ist das Fundament des agilen Projektmanagements. Es wurde im Februar 2001 von einer Gruppe von Entwicklern verfasst, die eine effizientere Methode zur Softwareentwicklung schaffen wollten. Das Manifest legt vier zentrale Werte fest:

1. Individuen und Interaktionen über Prozesse und Tools: Dies bedeutet, dass der Fokus auf den Menschen und ihrer Kommunikation liegt, anstatt auf starren Prozessen oder Werkzeugen.

2. Funktionierende Software über umfassende Dokumentation: Dieser Wert legt den Schwerpunkt auf das Liefern von nutzbaren Ergebnissen anstelle von detaillierten Berichten oder Dokumenten.

3. Zusammenarbeit mit dem Kunden über Vertragsverhandlungen: Dies bedeutet, dass die Zusammenarbeit mit Stakeholdern und deren Feedback während des gesamten Projekts wichtiger ist als langwierige Vertragsverhandlungen.

4. Reaktion auf Veränderung über das Festhalten an einem Plan: Dieser Wert betont die Bedeutung der Anpassungsfähigkeit und Flexibilität im Angesicht von Veränderungen und Unsicherheiten.

Diese Werte stellen die Grundlage für das Agile Projektmanagement dar und dienen als Leitfaden für die Durchführung agiler Projekte.

Die Rolle des Agilen Coaches

Ein Agiler Coach ist eine Person, die Teams bei der Anwendung und Implementierung agiler Methoden unterstützt. Entscheidend ist, dass ein Coach praktische Erfahrung als Projektmanager hat und sich nicht als Prediger von Standards versteht. Jedes Projekt ist anders, es kommt auf die Situation an!

Ein Agiler Coach hilft Teams nicht nur dabei, agile Methoden zu verstehen und anzuwenden, sondern unterstützt sie auch dabei, Hindernisse zu überwinden und kontinuierlich zu lernen und sich zu verbessern. Agile Coaches fungieren als Mentor, Trainer und Berater und tragen dazu bei, eine Umgebung zu schaffen, in der Teams effektiv zusammenarbeiten und hochwertige Ergebnisse liefern können.

Unterschiede zwischen klassischem und agilem Projektmanagement

Es gibt signifikante Unterschiede zwischen dem klassischen und dem agilen Projektmanagement.

Klassisches Projektmanagement

Im klassischen Projektmanagement ist der Umfang eines Projekts festgelegt, während Zeit und Aufwand variabel sind. Der Prozess ist linear und folgt dem Wasserfallmodell, bei dem jede Phase des Projekts nacheinander abgeschlossen wird. In diesem Modell sind die Rollen und Prozesse festgelegt und der Einfluss der Stakeholder nimmt im Laufe des Projekts ab.

Agiles Projektmanagement

Im Gegensatz dazu ist im agilen Projektmanagement die Zeit und der Aufwand festgelegt, während der Umfang variabel ist. Der Prozess ist iterativ, was bedeutet, dass alle Phasen des Projekts in einer Iteration durchlaufen werden. Der Prozess wird kontinuierlich verbessert und der Einfluss der Stakeholder bleibt während des gesamten Projekts konstant.

Ein weiterer wichtiger Unterschied besteht darin, dass im agilen Projektmanagement das Team selbst das Projekt managt und die Verantwortung übernimmt, während im klassischen Projektmanagement der Projektmanager das gesamte Projekt managt und verantwortet.

Vorteile des agilen Projektmanagements

Es gibt viele Vorteile, die das agile Projektmanagement gegenüber dem klassischen Projektmanagement bietet.

1. Flexibilität: Agile Projekte können sich schnell an Änderungen anpassen. Dies ist besonders vorteilhaft in Umgebungen, in denen sich die Anforderungen häufig ändern können.

2. Kürzere Feedbackzyklen: Durch kurze Iterationen und regelmäßige Überprüfungen können Teams schneller Feedback einholen und Probleme frühzeitig erkennen und beheben.

3. Kundenorientierung: Die enge Zusammenarbeit mit den Stakeholdern und das kontinuierliche Einholen von Feedback führen zu einer besseren Ausrichtung auf die Kundenbedürfnisse und zu höherer Kundenzufriedenheit.

4. Kontinuierliche Verbesserung: Agile Teams legen Wert auf kontinuierliches Lernen und Verbesserung. Dies führt zu einer ständigen Verbesserung der Prozesse und der Qualität der Ergebnisse.

Schlussfolgerungen

Agiles Projektmanagement ist eine leistungsstarke Methode, die Flexibilität und kontinuierliche Verbesserung fördert. Mit der richtigen Anleitung und Unterstützung  können Teams die Vorteile des agilen Projektmanagements voll ausschöpfen und erfolgreiche Projekte liefern. Obwohl sich das agile Projektmanagement in der Privatwirtschaft bereits als Standard etabliert hat, gibt es im öffentlichen Sektor noch viel Raum für Wachstum und Verbesserung. Mit den richtigen Werkzeugen und Techniken können jedoch auch hier agile Methoden erfolgreich implementiert und genutzt werden.

Hier einige Blog-Posts zu diesem Thema:

Agile Projekte sind gut strukturiert, nicht beliebig

„Disciplined Agile“ ist ein flexibler Standard, der die Einmaligkeit von Projekten berücksichtigt

Warum scheitern so viele IT-Projekte?

Warum Verträge oft Projekte zum Scheitern bringen

Was ist ein agiles Mindset und warum ist das wichtig?

Und hier der Link zum Buch „12 Halbwahrheiten über IT-Projekte“

Agile Methoden wie Scrum und Kanban haben das Versprechen, die Produktivität zu steigern und den Entwicklungszyklus zu verkürzen. Trotzdem scheitern viele agile Projekte. Wie kommt es dazu? Und was können wir dagegen tun?

Der Wert der Kommunikation

Die Kommunikation ist ein zentraler Aspekt der agilen Methoden. Die kontinuierliche und transparente Kommunikation zwischen allen Projektbeteiligten ist entscheidend für den Erfolg eines agilen Projekts. Fehlt es an effektiver Kommunikation, kann das Projekt scheitern.

Fristen und Schätzungen

Die Planung von Projektfristen kann schwierig sein. Fristen im agilen Projektmanagement werden oft auf der Grundlage von Annahmen geschätzt. Fehler können entstehen, wenn Projektfristen geplant werden, ohne alle möglichen Bedingungen zu berücksichtigen. Eine genaue Schätzung der Zeit und Ressourcen, die für die Projektarbeit benötigt werden, ist daher entscheidend.

Rolle des Scrum Masters

Der Scrum Master spielt eine wichtige Rolle im agilen Projektmanagement. Er ist dafür verantwortlich, das Team zu coachen und zu führen. Wenn der Scrum Master seine Rolle nicht richtig ausfüllt, kann das Projekt scheitern.

Das Team und seine Dynamik

In agilen Projektteams ist jeder ein Experte auf seinem Gebiet. Die Teammitglieder müssen effektiv zusammenarbeiten und ihre Meinungen in Entscheidungen einbringen. Ist die Teamdynamik gestört oder fehlen klare Rollen und Verantwortlichkeiten, kann das Projekt scheitern.

Der Faktor Kunde

Agile Projekte erfordern eine enge Zusammenarbeit mit dem Kunden. Wenn der Kunde nicht aktiv in den Entwicklungsprozess einbezogen wird, kann das zu Missverständnissen und Frustration führen, die das Projekt gefährden können.

Methodenwahl

Nicht jedes Projekt eignet sich für agile Methoden. Es ist wichtig, die richtige Methode für das Projekt zu wählen. Ein falscher Methodenansatz kann zu Schwierigkeiten und letztendlich zum Scheitern des Projekts führen.

Unternehmenskultur

Die Unternehmenskultur kann einen großen Einfluss auf den Erfolg eines agilen Projekts haben. Eine Kultur, die Innovation und Flexibilität fördert, kann agile Projekte begünstigen. Eine starre, traditionelle Unternehmenskultur kann hingegen hinderlich sein.

Fehlende Ziele

Ein klar definiertes Ziel ist ein wichtiger Erfolgsfaktor für jedes Projekt. Fehlen diese Ziele in einem agilen Projekt, kann das zu Verwirrung und mangelnder Motivation im Team führen.

Zu schnelle Skalierung

Die Einführung agiler Methoden erfordert Zeit und Geduld. Eine zu schnelle Skalierung kann zu Überforderung und Chaos führen, was das Projekt zum Scheitern bringen kann.

Fehlende Flexibilität

Agile Methoden erfordern Flexibilität. Wenn ein Projekt zu starr ist und sich nicht an Veränderungen anpassen kann, kann es scheitern. Es ist wichtig, dass das Projektteam offen für Veränderungen ist und sich anpassen kann, wenn es nötig ist.

Schlussfolgerung

Auch wenn agile Methoden viele Vorteile bieten, können auch sie zum Scheitern führen. Es ist wichtig, die häufigsten Gründe für das Scheitern von agilen Projekten zu kennen und Strategien zu entwickeln, um diese zu vermeiden. Mit guter Kommunikation, der richtigen Methodenwahl, klaren Zielen und einer offenen Unternehmenskultur kann man die Erfolgschancen von agilen Projekten deutlich erhöhen.

Noch im vorigen Jahrtausend habe ich einen Vortrag zum Thema „Rapid Application Development“ und „Fast Prototyping“ gehalten. Da das agile Manifest erst 2001 veröffentlicht wurde, gab es den Begriff „agil“ noch nicht als Standard, aber genau das war gemeint.

War ich gegen oder für solche Vorgehensmodelle? Ehrlich gesagt habe ich das schon damals als eine Frage des „Wie“ und nicht des „Ob“ gesehen.

Lange Zeit wurde „agil“ mit Misstrauen betrachtet und man musste argumentieren, warum man so vorgehen will. Mittlerweile hat sich das komplett gedreht, in vielen Organisationen ist „agil“ der Standard und „Wasserfall“ ein No-Go. Ich habe die lustige Erfahrung gemacht, dass ich bei ein und demselben Projektsponsor einmal mein agiles Vorgehen tarnen musste und 5 Jahre später war agiles Vorgehen seine Vorgabe. Ob aus tiefster Überzeugung, wage ich zu bezweifeln, das überbordende Mikromanagement in diesem Projekt spricht eindeutig dagegen.

Aber zurück zum Titel: Ich halte das Vorgehen nach dem Wasserfallmodell für ideal und höchst erstrebenswert. Ein umfassender Plan zu Beginn der Arbeit, eine Schritt-für-Schritt-Realisierung, bei der das Ergebnis jeder Phase die Grundlage für die nächste Phase bildet und am Ende der ursprüngliche Plan bis auf wenige Change Requests erfolgreich umgesetzt wurde.

Aber auch hier gilt mit Bertolt Brecht „Doch die Verhältnisse, sie sind nicht so!“ Denn sie sind VUKA (volatil, unsicher, komplex, ambivalent).

Oder gibt es sie doch noch, die Projekte, die sich für das Wasserfallmodell eignen? Ich bin seit vielen Jahren vorwiegend in der öffentlichen Verwaltung tätig, aber auch vor Covid-19 habe ich nie erlebt, dass die Voraussetzungen für ein klassisches Wasserfallmodell gegeben waren. Agile Vorgehensmodelle sind also auch in einer als stabil geltenden Branche ein Muss.

Was mich allerdings zunehmend irritiert, ist die dogmatische Herangehensweise an das Thema Agilität, die sich in den letzten Jahren breit gemacht hat. Typisch dafür: Egal worum es geht, wir machen Scrum! Anforderungen gibt es nur noch als User Story, auch wenn vielleicht eine Entscheidungstabelle oder ein Set von Testfällen präziser wäre. Noch seltsamer finde ich es, wenn technische Anforderungen an Schnittstellen krampfhaft in User-Stories umgeformt werden. Ich muss allerdings die Urheber von Scrum vor ihren Fans in Schutz nehmen, denn der Scrum-Guide hat inzwischen das Wort „User-Story“ gestrichen und durch „Backlog-Item“ ersetzt. Anscheinend haben viele Scrum-Fans nach ihrer Zertifizierung aufgehört, sich weiterzubilden.

Das Vorgehen in einem Projekt muss dem Erfolg dienen. „One size fits all“ gilt auch für Vorgehensmodelle nicht. Scrum hat viele Vorteile, passt aber nicht immer. Manchmal ist Kanban (Lean) oder XP die bessere Variante. Und man kann auch Elemente kombinieren, wir sind keiner reinen Lehre verpflichtet. Hybrid wird meist für die Kombination von klassischem Vorgehen (Wasserfall) mit agilen Methoden verwendet, gilt aber meiner Meinung nach auch für die Kombination von agilen Methoden. Gerade XP wird meiner Meinung nach zu Unrecht vernachlässigt: Pair Programming, Refactoring, Test Driven Development sind sehr nützliche Methoden, die in jedem Setting eingesetzt werden können.

Agilität steht für Offenheit, Innovation, Flexibilität und wohl auch Vielfalt. Trotzdem höre ich in der Praxis als Konkretisierung von agilem Projektmanagement so gut wie immer nur ein Modell: Scrum. Kürzlich las ich in einem Angebot auch die Formulierung: „Unser Vorgehen beruht auf dem Industriestandard Scrum“. Also so etwas wie „Stand der Technik“. Ist also Scrum de facto alternativlos, das letztlich einzige praxistaugliche Modell, um agile Softwareentwicklung zu betreiben? Wäre ja schön, wenn wir uns alle einig wären und nur noch eine Methodik lernen müssten.

„Nie wieder denken!“ so hat vor einigen Jahren ein Methodenberater sein Framework angepriesen. Allerdings hat er uns in dem Projekt, wo er als Berater engagiert worden war, gut 9 Monate gekostet, bis es mir mit einigen Mitstreitern gelungen ist, die Projektarbeit auf eine vernunftbasierte und ergebnisorientierte Arbeitsweise umzustellen. Ich bin seither allergisch gegenüber umfassenden Geltungsansprüchen, oder salopp gesprochen auf Leute, die meinen, die Wahrheit gepachtet zu haben.

Wenn aber Scrum so erfolgreich ist, dann hat das sicher einen Grund. Ein entscheidender Grund ist meiner Überzeugung nach, dass Scrum einfach und klar ist. Eine hervorragende Darstellung geben die 24. Ich muss hier nicht auf die Details eingehen, die meisten Leser meines Newsletters wissen ohnehin sehr genau, wie Scrum definiert ist.

Scrum kompakt dargestellt (Quelle: Agile Fanatics)

Im Scrum-Guide schreiben die „Erfinder“ von Scrum, Ken Schwaber und Jeff Sutherland dazu: „Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.“ Und weiter: „Scrum ist einfach. Probiere es so aus, wie es ist, und finde heraus, ob seine Philosophie, Theorie und Struktur dabei helfen, Ziele zu erreichen und Wert zu schaffen. Das Scrum-Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind. Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden. Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen.“

Wenn in der Praxis Scrum von manchen agilen Coaches verabsolutiert wird, liegt das nicht an den Autoren des Scrum-Guides, den diese als bewusst unvollständig und als nicht immer passend charakterisieren.

Ich bin „Disciplined Agile Senior Scrum Master“, stehe daher hoffentlich nicht im Verdacht, Scrum nicht zu verstehen oder pauschal abzulehnen. Ich habe auch in der Praxis schon mit Scrum-Teams (erfolgreich) gearbeitet. Aus diesen Erfahrungen heraus muss ich allerdings einige kritische Hinweise zur Scrum-Praxis geben.

Wo ist Scrum unvollständig?

a. Scrum ist keine Projektmanagement-Methodik.

Das Wort „Projekt“ kommt im Guide nur einmal vor: „Jeder Sprint kann als ein kurzes Projekt betrachtet werden.“ Das kann man so sehen. Allerdings ist jeder Sprint selbst Teil eines Projektes und es gibt in jedem Projekt zahlreiche Elemente, die nicht sinnvoll gemäß Scrum abgewickelt werden. So z.B. Beschaffungsprozesse für Standardsoftware und Hardware, Steuerung und Integration von Entwicklungsarbeiten, die nicht vom Scrum-Team durchgeführt werden etc. Wie vielfältig Projektmanagement ist, zeigt allein die Tatsache, dass PMI den Aufgabenbereich des Projektmanagements durch 49 Prozesse innerhalb der folgenden fünf Prozessgruppen beschreibt:

1. Initiierung

2. Planung

3. Ausführung

4. Überwachung und Steuerung

5. Abschluss oder Umsetzung.

Scrum adressiert die Prozessgruppen 3 und 4 und gibt dafür sehr konkrete und in vielen Fällen sinnvolle Vorgaben. Aber es bleibt viel offen. Der Scrum-Guide betont zwar: „Das Scrum-Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind.“ An anderer Stelle steht allerdings (Hervorhebung von mir): „Innerhalb des Rahmenwerks können verschiedene Prozesse, Techniken und Methoden eingesetzt werden. Scrum umhüllt bestehende Praktiken oder macht sie überflüssig.“ Es sollte klargestellt werden, dass Scrum bestehende Praktiken außerhalb des Scrum-Rahmenwerkes nicht überflüssig macht, im Gegenteil, diese sogar zwingend voraussetzt. Dazu gehört alles, was ein Projekt außerhalb der Entwicklung im engeren Sinne beinhalten muss, um erfolgreich zu sein.

b. Scrum setzt Architekturentscheidungen stillschweigend voraus

Die Entscheidung für eine bestimmte technische Plattform, für oder gegen eine Standardsoftware, die Art der Integration einer neuen Anwendung in die Applikationslandschaft, die Nutzung oder Nicht-Nutzung einer Business Rule Engine etc. sind Weichenstellungen, die enorme Auswirkungen auf den Erfolg eines IT-Projektes haben. Diese Weichenstellungen erfolgen typischerweise vor dem Start der iterativen Entwicklung gemäß dem Scrum-Paradigma. Da Scrum ein Prozessmodell ist, das sich gegenüber Inhalten völlig agnostisch verhält, ist dieser blinde Fleck kein Bug, sondern ein Feature.

c. Scrum wälzt zu viel Verantwortung auf den/die Product Owner:in ab

Die Reihenfolge der Umsetzung von Anforderungen hängt wesentlich auch von der Architektur der technischen Lösung ab. Wenn also ein Product-Owner „die Reihenfolge der Product-Backlog-Einträge festzulegen“ hat und insgesamt „ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt“ist, so blendet das völlig aus, dass solche Entscheidungen eine Abstimmung zwischen Business und IT erfordern. Implementierungsschritte bauen aufeinander auf. So muss z.B. eine Basiskomponente gebaut werden, mit der dann Konfigurationen möglich sind. Würde der Product Owner darauf bestehen, dass gewisse Funktionen vorher implementiert werden, könnte das nur durch hartes Codieren erfolgen und dieses Provisorium müsste dann wieder ausgebaut werden, wenn die Konfigurationsmöglichkeit bereit ist. Bei einer konfigurierbaren Standardsoftware kann hingegen sofort mit der Konfiguration von Funktionen begonnen werden und die Reihenfolge kann nach fachlichen Gesichtspunkten bestimmt werden. Ich habe als Product Owner großes Erstaunen bei in der Wolle gefärbten Scrummern geerntet, wenn ich sie aufgefordert habe, mir ihre Empfehlung zur Reihenfolge der Umsetzung zu geben.

Es wird auch übersehen, dass Priorisierung ein mehrdimensionales Konzept ist, zumindest muss zwischen Wichtigkeit und Dringlichkeit unterschieden werden. Vor der Produktivsetzung können wichtige und daher unverzichtbare Features auch relativ spät implementiert werden, ohne dass die Entwicklung dadurch Schaden leidet. Das gilt etwa für Schnittstellen oder auch Berechnungsroutinen, die einige Zeit durch Mockups hinreichend substituiert werden können.

Wie sollten wir Scrum nutzen?

Scrum bietet eine Reihe von Methoden, die bei der Abwicklung von IT-Projekten hohen Nutzen bieten können. Allerdings muss man diese Aussage wirklich ernst nehmen: „Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden. Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen“. Um zum Methodenberater vom Anfang zurückzukehren, gilt: Denken! Immer!

Scrum ist nicht immer das ideale Vorgehensmodell. Lean oder XP sind Alternativen, die man nicht außer Acht lassen darf. Natürlich kann man auch Elemente wie Pair Programming oder Test Driven Development innerhalb eines Scrum-Projektes nutzen. Ich sehe auch regelmäßig, dass Scrum-Teams ein Kanban-Board nutzen, obwohl sie nicht insgesamt einem Lean-Ansatz folgen.

Methodischer Eklektizismus ist kein Verrat an den Prinzipien agiler Softwareentwicklung, sondern meiner Meinung nach Best Practice. Es muss „nur“ funktionieren. Wenn allerdings etwas in einem Projekt nicht funktioniert, dann muss man das Vorgehen ändern und sich nicht krampfhaft an den Standard klammern.