becoming self employed – 12 questions that keep you from it and how I answered them

This week, after ten years of being an employee, I’ve started my new career as an independent agile coach and kanban trainer. While I feel way more motivated and super positive we all know our weaker self. These are the questions I had to answer “it”.
(It is known, that our weaker self starts questions with a BUT and oftentimes ends them with a ! instead of a ?)

But Markus, think about the safety you had with your previous employer!
A quote from “the matrix” comes to mind: „try to realize the truth! there is no spoon“ – the same is true for job security. In case of a consultancy, if you’re not „sold“ to a customer, there is a limited amount of undesirable jobs you can do – not more, and not less. You have to see the fact, that you are employed to create value for your employer. As soon as you’re not doing that, you’re out.

But Markus, you won’t get paid when you’re ill!
Let’s boil it down to money then.. how many days per year don’t you have a cold? The amount of money you make on these days hopefully far exceeded your sick leave.

But Markus, what if you get too many customers and just can’t handle all of them?
Well, the good thing in the agile (and most other) communities is, that you can always get help if you choose to ask for it. If indeed, you have too much on your plate, ask a fellow peer if she wants to help out or knows other coaches, facilitators or trainers that are looking for contracts at the moment.

You might even find the perfect fit for a customer you could only halfheartedly help.

But Markus, what if your customer doesn’t pay you?
Same thing as with every other aspects of your life. It is wise to have a legal costs insurance.

But Markus, nobody will pay for your education/trainings!
You are right, weaker self. There is no boss interested in my education.
And there shouldn’t be. Nobody should be more interested in my personal development than myself! It helps to set aside some (or a lot of) money to pay for the trainings I (or my fellow peers) deem useful for me.
A good friend of mine has set a minimum of 10.000eur/year for his own advancement. He knows that knowledge – and the application of it – distinguishes him from the competition.

I will set aside a similar sum per year for sharpening my mind. Maybe 10% of my income?

But Markus, you as a one man show don’t scale!
Indeed. If I wanted to „scale“, I would take a closer look at companies like crisp, oose, it-agile or kegon. These companies chose to reinvent themselves, thereby creating happier employees and also happier customers.

But Markus, what if your customers are abroad/want you to travel?
Then, my dear weaker self, it is totally up to me, if that customer fits into my current style of living.

But Markus, how can you survive in a market so full of amazing agile coaches?
Most colleagues of mine have their unique selling point. The same is true for me.
If you want to know more about it, just klick here.
For my german speaking readers: There is an amazing 3min youtube video called “Das Pinguin Prinzip”. Take a look if you understand some german.

But Markus, how can you possibly manage your time without a boss, a bonus or goals to drive you?
Weaker self, we both have read “Drive” by Daniel Pink. You should know how little I think of monetary bonuses or performance appraisals for skillful or creative work.

But Markus, are you not scared you won’t find a “real” Job, if you ever decided to go “corporate” again?
You are right, some companies don’t accept CV’s of candidates that have been self-employed. The question you should ask yourself is:

  • Why would an employer not want candidates with an entrepreneurial spirit?
  • Would you want to work for a company like that?

I will combine the next four questions…
But Markus, how will you acquire new clients if you’re working all the time?
But Markus, what if you can’t work with big firms for legal reasons? (payrolling)
But Markus, what about your retirement plans?
But Markus, won’t you hate doing tax reports and all the other back office stuff?
Now we’re looking at the „real“ problems, that need real solutions.
At the moment, I’m handling my customers through a supplier/provider.
What does that mean? I’m basically employed by them and get my hourly rates on the 10th of the next month with some percentage for back office, contract creation, retirement plans, taxes and so on.
I will invest more time at conferences, meetups and so on to reinvent myself as a „product“ and find new customers. Already some of my previous customers are helping me to spread the word, which I’m very thankful for.

But Markus, is it really worth the trouble?
I can only speak from the experience I got from the last three days.
So far my answer is: „Yes, yes, yes! I should have done it earlier.“

I’d love to hear read your comments on being self employed, or why you think it is a bad idea after all!

Is SAFe unSAFe – My Thoughts

Thoughts on how the Scaled Agile Framework is perceived by some agilists

At the moment the Scaled Agile Framework is getting a lot of attention as it provides answers to challenges common for large scale agile initiatives / large agile programs. SAFe being an agile/lean framework is also part of the Agile 2013 conference, something Ken Schwaber doesn’t seem to like:

Beside this tweet Ken also wrote a small article where he explains (his impression) that SAFe might be more dangerous as helpful as it has it’s root in RUP and Processes & Tools are overemphasized in comparison to People & Interactions:

Ken Schwaber’s Blog: Telling Like It Is – unSAFe at any speed.

While the article itself lacks some substance (you just notice how uncomfortable Ken is with SAFe) the comments are very interesting as real practitioners share thoughts and their experience with SAFe (good ones, bad ones).

*Updated*

A far more detailed article has been written by David Anderson (Mr. Software Kanban) in which he also expresses his concerns regarding SAFe. He wrote his article „Kanban – the anti-SAFe for almost a decade already“ about SAFe but also acknowledged that he just did some brief research and has no real experience with it:

To be honest, I don’t know a great deal about SAFe.

Still his summary is:

It is fair to say that this approach is the antithesis of the Kanban Method!

and also adds

I’m not impressed with the Kanban related material or its suggested usage in SAFe.

From his point of view

SAFe appears to collect together a number of techniques from software development processes from the 1990s and 2000s. It offers these as one large framework.

With that he seems to underestimate how many feedback cycles (learning & improving) during the last years finally resulted in what is now known as SAFe and he completely misses (from my perspective) the embedded Lean Product Development Principles (Donald Reinertsen) and the Lean Leadership foundation (part of the SAFe Lean Thinking House).

As you might have noticed I do not share the opinions of Ken Schwaber or David Anderson but I am happy to see that these two thought leaders finally found something they can agree on.

What are my thoughts on the Scaled Agile Framework?

SAFe is prescriptive – but it is just the start of your journey

From my own experience the implementation of SAFe is a quite challenging undertaking as SAFe seems to be a quite prescriptive framework with a lot of guidance and governance („Processes & Tools“) but still you have to have a deep understanding of the agile / lean foundations to implement (tailor, adapt) it in an organization specific way („People & Interactions“). I personally feel it is worth the effort because SAFe provides a proven framework with values, principles and best practices that address the common challenges you have to overcome when scaling agile and especially when scaling agile in a non green field environment. Having said that I believe it is key that you teach/establish real agile/lean thinking and learning cycles so the organization can further adapt and improve  („Kaizen“). Only with these Inspect & Adapt cycles „SAFe“ is going to work for your organization on the long run.

There are a lot more topics to discuss and to improve over time (your „SAFe Path“):
maus-lesend

  • how to find / optimize your agile release trains
  • how to do the portfolio planning in your context
  • how to optimize the demand management
  • how to prioritize in a scaled environment
  • what to do with the HIP sprint
  • when and how to release to production (the shorter the cycles the better)
  • how to facilitate & organize the inspect & adapt workshop for optimal group feedback
  • decide on which KPIs are really important for your company

Failing to see that this is the journey your organization needs to undertake will leave you stuck in the predefined default practices / processes / tool that you can find on the SAFe website. Keep in mind: Real agile-lean companies are always learning, adapting and improving.

Resistance as it is not Agile?

In companies that have existing Scrum teams I usually experience some resistance of agile practitioners as the team level loses some freedom of choice. Have a look at the role of the SAFe Product Owner for example, the need to have cadence AND synchronization or the need to commit to several sprint during the release planning event (sounds weird for most agile people who did not experience such an event before).

Global optimization required

Very often these people need to be trained to see the value of overall alignment and enterprise wide transparency (see SAFe Cove values). Single teams excelling in their own context _may_ sum up to a lot of local optima but (at the same time) may not be useful to reach a global (organization) optimization. Not understanding this is like not understanding how your company is creating value.

Role of Scrum in SAFe

Important to note is also that SAFe is not against Scrum but uses the principles of Scrum as a team process (perfect match for most teams in a SAFe environment) and Scrum as thinking model (guiding you how to organize and optimize your organization). However one could argue that it is not „Scrum.org Scrum“ as there are some adjustments made (as with most Scrum implementations „in the wild“) but still it shares the same spirit and goals, taking inspiration also from Donald Reinertsen’s Product Development Principles not only for developing products but also for improving the own processes.

What does really matter? It’s you!

While SAFe is about alignment, transparency, program execution and (code) quality it’s about how YOU are going to implement the ideas, principles and practices in YOUR environment. In the end it’s the implementation that matters: It’s you, your colleagues, your shared goals/values and the business value you produce.

Thoughts on how the Scaled Agile Framework is perceived by some agilists

At the moment the Scaled Agile Framework is getting a lot of attention as it provides answers to challenges common for large scale agile initiatives / large agile programs. SAFe being an agile/lean framework is also part of the Agile 2013 conference, something Ken Schwaber doesn’t seem to like:

Beside this tweet Ken also wrote a small article where he explains (his impression) that SAFe might be more dangerous as helpful as it has it’s root in RUP and Processes & Tools are overemphasized in comparison to People & Interactions:

Ken Schwaber’s Blog: Telling Like It Is – unSAFe at any speed.

While the article itself lacks some substance (you just notice how uncomfortable Ken is with SAFe) the comments are very interesting as real practitioners share thoughts and their experience with SAFe (good ones, bad ones).

*Updated*

A far more detailed article has been written by David Anderson (Mr. Software Kanban) in which he also expresses his concerns regarding SAFe. He wrote his article „Kanban – the anti-SAFe for almost a decade already“ about SAFe but also acknowledged that he just did some brief research and has no real experience with it:

To be honest, I don’t know a great deal about SAFe.

Still his summary is:

It is fair to say that this approach is the antithesis of the Kanban Method!

and also adds

I’m not impressed with the Kanban related material or its suggested usage in SAFe.

From his point of view

SAFe appears to collect together a number of techniques from software development processes from the 1990s and 2000s. It offers these as one large framework.

With that he seems to underestimate how many feedback cycles (learning & improving) during the last years finally resulted in what is now known as SAFe and he completely misses (from my perspective) the embedded Lean Product Development Principles (Donald Reinertsen) and the Lean Leadership foundation (part of the SAFe Lean Thinking House).

As you might have noticed I do not share the opinions of Ken Schwaber or David Anderson but I am happy to see that these two thought leaders finally found something they can agree on.

What are my thoughts on the Scaled Agile Framework?

SAFe is prescriptive – but it is just the start of your journey

From my own experience the implementation of SAFe is a quite challenging undertaking as SAFe seems to be a quite prescriptive framework with a lot of guidance and governance („Processes & Tools“) but still you have to have a deep understanding of the agile / lean foundations to implement (tailor, adapt) it in an organization specific way („People & Interactions“). I personally feel it is worth the effort because SAFe provides a proven framework with values, principles and best practices that address the common challenges you have to overcome when scaling agile and especially when scaling agile in a non green field environment. Having said that I believe it is key that you teach/establish real agile/lean thinking and learning cycles so the organization can further adapt and improve  („Kaizen“). Only with these Inspect & Adapt cycles „SAFe“ is going to work for your organization on the long run.

There are a lot more topics to discuss and to improve over time (your „SAFe Path“):
maus-lesend

  • how to find / optimize your agile release trains
  • how to do the portfolio planning in your context
  • how to optimize the demand management
  • how to prioritize in a scaled environment
  • what to do with the HIP sprint
  • when and how to release to production (the shorter the cycles the better)
  • how to facilitate & organize the inspect & adapt workshop for optimal group feedback
  • decide on which KPIs are really important for your company

Failing to see that this is the journey your organization needs to undertake will leave you stuck in the predefined default practices / processes / tool that you can find on the SAFe website. Keep in mind: Real agile-lean companies are always learning, adapting and improving.

Resistance as it is not Agile?

In companies that have existing Scrum teams I usually experience some resistance of agile practitioners as the team level loses some freedom of choice. Have a look at the role of the SAFe Product Owner for example, the need to have cadence AND synchronization or the need to commit to several sprint during the release planning event (sounds weird for most agile people who did not experience such an event before).

Global optimization required

Very often these people need to be trained to see the value of overall alignment and enterprise wide transparency (see SAFe Cove values). Single teams excelling in their own context _may_ sum up to a lot of local optima but (at the same time) may not be useful to reach a global (organization) optimization. Not understanding this is like not understanding how your company is creating value.

Role of Scrum in SAFe

Important to note is also that SAFe is not against Scrum but uses the principles of Scrum as a team process (perfect match for most teams in a SAFe environment) and Scrum as thinking model (guiding you how to organize and optimize your organization). However one could argue that it is not „Scrum.org Scrum“ as there are some adjustments made (as with most Scrum implementations „in the wild“) but still it shares the same spirit and goals, taking inspiration also from Donald Reinertsen’s Product Development Principles not only for developing products but also for improving the own processes.

What does really matter? It’s you!

While SAFe is about alignment, transparency, program execution and (code) quality it’s about how YOU are going to implement the ideas, principles and practices in YOUR environment. In the end it’s the implementation that matters: It’s you, your colleagues, your shared goals/values and the business value you produce.

SAFe Big Picture 2.5

Big Picture 2.5 veröffentlicht

Für das Scaled Agile Framework ist die Version 2.5 des Big Picture (und damit der Einstiegsseite) veröffentlicht worden.

„I am excited for the SAFe community to visit the updated portfolio content (Portfolio Vision, Value Streams, and Portfolio Backlog) and program updates (Release Planning, Program Objectives, and Team PSI Objectives). In addition, we’ve further built out our case studies and made it a top-level navigation menu.“ –Dean Leffingwell

Die meisten Änderungen betreffen die mittlere Ebene (SAFe Program). Dort wird jetzt besonders hervorgehoben, welche Ziele das Release Planning verfolgen soll: Ausgehend von einer Vision, Roadmap und einem Planungszenario erarbeiten Geschäftsseite und Technikseite gemeinsam einen belastbaren Plan. Für jeden Sprint formulieren die Teams ihre eigenen Sprint-Ziele, zudem formuliert jedes Team ein Ziel für das gesamte PSI (Release). Diese „Team PSI Objectives“ werden schließlich zu „Program PSI Objectives“ aggregiert. Dies geschieht immer im Zusammenspiel mit Vertretern aus dem Management, den sogenannten „Business Ownern„. Da diese sehr wichtig sind und meist auch Programm-übergreifend tätig sind, werden diese nun im Big Picture erwähnt (zuvor wurde lediglich auf sie verwiesen und waren im BP implizit dem Program Portfolio Management und ggf. dem Product Management zugeordnet).

Neu auf der Programm-Ebene sind zudem die DevOps, deren Aufgabe die Sicherstellung einer enge Zusammenarbeit zwischen Entwicklungs- und Betriebsorganisation ist (die oft noch weiter gefassten Definitionen von DevOps finden hier zunächst keine Anwendung). Zuvor wurde diese Aufgabe zum Teil durch das System Team wahrgenommen.

Übersicht Änderungen

Portfolio-Ebene

  • Value Streams werden explizit erwähnt

Programm-Ebene

  • DevOps – als primäre Rolle eingeführt
  • „Shared“ – Rolle entfällt aus dem BP
  • BO / Business Owner – als primäre Rolle eingeführt
  • PSI Program Objectives – als Artefakt aufgenommen
  • Team PSI Objective – als Artefakt aufgenommen
  • Deliver on Demand – als Guidance aufgenommen
  • generell wurde das Layout etwas geändert (Arch, UX, RTE auf den ART, ein gewöhnungebedürftiges Grün für Auslieferungen)

Team-Ebene

  • Sprint Goals – als verbindliches Artefakt jetzt in das BP aufgenommen (war auch zuvor in der Beschreibung zum Release Planning als verbindlich beschrieben)
  • DBT (Design-Build-Test) – entfällt (eine Änderung, die Kritik hervorgerufen hat)
  • Code Quality – jetzt explizit erwähnt im BP
  • Develop on Cadence – als Guidance aufgenommen
  • EXE – Guidance zu „Sprint Execution“

Für das Scaled Agile Framework ist soeben die Version 2.5 des Big Pictures veröffentlicht worden.

 

Dean Leffingwell hierzu: „I am excited for the SAFe community to visit the updated portfolio content (Portfolio Vision, Value Streams, and Portfolio Backlog) and program updates (Release Planning, Program Objectives, and Team PSI Objectives). In addition, we’ve further built out our case studies and made it a top-level navigation menu.“

 

Die meisten Änderungen betreffen die mittlere Ebene (SAFe Program). Dort wird jetzt besonders hervorgehoben, welche Ziele das Release Planning verfolgen soll: Ausgehend von einer Vision, Roadmap und einem Planungszenario erarbeiten Geschäftsseite und Technikseite gemeinsam einen belastbaren Plan. Für jeden Sprint formulieren die Teams ihre eigenen Sprint-Ziele, zudem formuliert jedes Team ein Ziel für das gesamte PSI (Release). Diese „Team PSI Objectives“ werden schließlich zu „Program PSI Objectives“ aggregiert. Dies geschieht immer im Zusammenspiel mit Vertretern aus dem Management, den sogenannten „Business Ownern„. Da diese sehr wichtig sind und meist auch Programm-übergreifend tätig sind, werden diese nun im Big Picture erwähnt (zuvor wurde lediglich auf sie verwiesen und waren im BP implizit dem Program Portfolio Management und ggf. dem Product Management zugeordnet).

Neu auf der Programm-Ebene sind zudem die DevOps, deren Aufgabe die Sicherstellung einer enge Zusammenarbeit zwischen Entwicklungs- und Betriebsorganisation ist (die oft noch weiter gefassten Definitionen von DevOps finden hier zunächst keine Anwendung). Zuvor wurde diese Aufgabe zum Teil durch das System Team wahrgenommen.

 

In Summe gibt es folgende Änderungen:

Portfolio-Ebene

  • Value Streams werden explizit erwähnt

Programm-Ebene

  • DevOps – als primäre Rolle eingeführt
  • „Shared“ – Rolle entfällt aus dem BP
  • BO / Business Owner – als primäre Rolle eingeführt
  • PSI Program Objectives – als Artefakt aufgenommen
  • Team PSI Objective – als Artefakt aufgenommen
  • Deliver on Demand – als Guidance aufgenommen
  • generell wurde das Layout etwas geändert (Arch, UX, RTE auf den ART, ein gewöhnungebedürftiges Grün für Auslieferungen)

 

Team-Ebene

  • Sprint Goals – als verbindliches Artefakt jetzt in das BP aufgenommen (war auch zuvor in der Beschreibung zum Release Planning als verbindlich beschrieben)
  • DBT (Design-Build-Test) – entfällt (eine Änderung, die Kritik hervorgerufen hat)
  • Code Quality – jetzt explizit erwähnt im BP
  • Develop on Cadence – als Guidance aufgenommen
  • EXE – Guidance zu „Sprint Execution“

Scaling Agile & Lean – Spotify Squads, Tribes and Chapters

Die Reihe „Scaling Agile & Lean“

Agile Methoden wie Scrum werden mittlerweile in den meisten Unternehmen eingesetzt, einige Studien gehen davon aus, dass 80% aller Unternehmen agile Prozesse einsetzen, konservativere Studien sprechen von etwas mehr als der Hälfte. In den meisten Fällen dürfte sich dies jedoch weiterhin auf den Einsatz von Scrum oder Kanban in Teilbereichen der Unternehmen, wenigen Teams oder Projekten beschränken.

Ansätze, um hinweg über viele Teams zu skalieren (Scaling Agile) fehlen häufig und werden für größere Unternehmen die auf Agilität setzen möchten immer wichtiger. Häufig scheitern Implementierungen von Scrum jedoch an dem fehlenden übergeordneten Koordinierungsbedarf, da der Fokus in den meisten Fällen zu sehr auf die Entwicklungs-Teams und weniger auf die Unternehmens- oder Portfolioebene gelegt wird. Besonder viele Reibungsverluste gibt es bei der Integration von agilen Organisationsteilen (z.B.: Entwicklung von neuen Systemen) und weiterhin eher traditionell organisierten Organisationsteilen (z.B.: Vertriebsorganisation, Abteilungen mit Fokus auf Wartung, Zulieferer).

Die Fragestellung, wie agile Methoden in größeren Unternehmen eingesetzt werden können, ist jedoch nicht neu. In der Reihe „Scaling Agile & Lean“ stellen wir einige der bekanntesten Frameworks und Methoden die hierbei Anwendung finden vor.

Scaled Agile @ Spotify im Detail

Einen sehr interessanten Ansatz für die Skalierung von agilen Teams verfolgt Spotify. Hier wurde auf über 30 Teams („Squads“) skaliert. Teams die in einem Kontext arbeiten, werden in sogenannten „Tribes“ gruppiert.  Der Kontextübergreifende Austausch geschieht durch die Etablierung von so genannten “Chapters”.

Diese Begrifflichkeiten mögen für einige gewöhnungsbedürftig sein aber sind sicherlich für viele Agilisten attraktiv, da diese häufig den klassischen Methodenwerken schon alleine wegen der vielfach missbrauchten Begrifflichkeiten ablehnend gegenüber stehen.

Liefereinheiten

Squad

Entspricht in etwa den üblichen agilen Teams, wobei kein spezifisches Vorgehen oder Framework wie beispielsweise Scrum oder Kanban vorgeschrieben ist. Es gibt einen Product Owner, der die Themen vorgibt und jemanden, der sich um das Team und die Einhaltung von Regeln kümmert (“Agile Coach”). Der “Agile Coach” gehört nicht ausschließlich zu einem Squad er muss aber für „seine“ Mitarbeiter verfügbar sein.

Scaling Agile @ Spotify
Scaling Agile @ Spotify

V-Modell XT 1.4

Kurzmitteilung

Stefan Hagen greift einen Artikel im GPM-Blog zum V-Modell XT 1.4 auf und verlinkt auch gleich auf weiterführende Dokumentation des V-Modells XT.

Das V-Modell XT wurde seit der Überarbeitung im Jahr 2005 u.a. auch stärker in Richtung agiler und inkrementeller Ansätze angepasst. Eingefleischte “Agilisten” ordnen das V-Modell XT aber recht klar der Kategorie der “Wasserfallmodelle” zu.

http://pm-blog.com/2012/06/04/v-modell-xt-in-der-version-1-4/

Die Agilisierung klassischer Phasenmodelle kann überall beobachtet werden. Zeit sich (mal wieder) mit der aktuellen Fassung des V-Modell XT zu bschäftigen ;-)

 

Die Motivation und Velocity des Teams spielerisch steigern

Nach den teilweise kritischen Kommentaren meines Teams (in der vorletzten Retro) und den inspirierenden Kommentaren zu meinem Artikel „Velocity einzelner Team-Mitarbeiter visualisieren“, haben wir im letzten Sprint eine verbesserte Version der Visualisierung gewählt.

Diese stellt nicht zwingend den schnellsten Entwickler über die anderen Teammitglieder, sondern bevorzugt ein gemeinsames Abarbeiten von Stories im Team.

Wir nennen es:

Storypointopoly

Velocity einzelner Team-Mitarbeiter visualisieren?

Im letzten Sprint – als ich in der „Done“ Spalte nach einem gewissen Ticket suchte – musste ich mit großer Überrschung feststellen, dass einer der Entwickler DEUTLICH mehr Tasks erledigt hatte, als die Anderen.

Es ist korrekt, dass die Tickets, die er bis zu diesem Zeitpunkt gemacht hatte, vom Aufwand kleiner waren als die, die sich andere Mitglieder des Teams vorgenommen hatten – der Unterschied war aber gravierend.

Agile Architektur

Agilität und Software-Architektur sind immer für eine Diskussion gut. Ich kann mich gut an diverse (hitzige) Diskussionen erinnern, in denen von stark traditionell geprägten Architekten gefordert wurde, dass doch bitte die Architektur detailliert im Vorfeld zu erstellen wäre. Zudem müsse man sich zu Projektstart darauf festlegen, welche Referenzumgebungen genutzt werden sollen, welche Technologien relevant sind und wie die nicht-funktionalen Anforderungen im Detail lauten. Das ergebe sich doch automatisch aus dem Scope und überhaupt müssen die typischen Sichten auf die Architektur detailliert geplant und beschrieben werden, bevor mit der Umsetzung begonnen wird. Eine Freigabe des Ganzen vor Eintritt in die Umsetzungsphase ist natürlich auch noch bei den entsprechende Entscheidungsinstanzen einzuholen.

Eine Ansicht, die in einem Phasenmodell ohne echte inkrementelle Elemente nicht ganz unbegründet ist und auch einen gewissen Wert hinsichtlich Identifikation und Bewertbarkeit von Risiken darstellt.

Die Realität: Architekturbeschreibung meist veraltet

Wie sieht die Realität in vielen Fällen aus? Eine Vielzahl an umfangreichen Modellierungsartefakten, eine Architektur die die Änderungen im Projektverlauf nicht abbilden kann. Kurz: Eine anfangs schöne Architekturvorstellung gleitet in einen „Architektursumpf“ ab. Der Ruf nach großen Re-Design Phasen wird laut (neue Dokumente, Modelle, Reviews, Freigaben). Das eigentliche Ziel, lauffähige Software zu liefern gerät schnell in den Hintergrund.