Das sagena Manifest

sagena Innovationsgesellschaft mbH

Auch wenn der Begriff „Manifest“ auf den ersten Blick etwas hochtrabend klingt, so sind die folgenden Punkte in der Tradition des „Manifesto for Agile Software Development“ genau dies - eine öffentliche Erklärung unserer Absichten und Ziele, damit es für Sie „handgreiflich“ wird, auf welchen Werten und Konzepten unsere Arbeit beruht.

Unsere Werte

Obwohl die folgenden fünf Werte erst viele Jahre nach seiner ersten Fassung in den Scrum-Guide aufgenommen wurden, standen sie als "geronnene Empirie" implizit schon lange im Raum. Wir haben diesen Schritt besonders begrüßt, weil für uns die zentrale Bedeutung dieser Werte und ein gemeinsames Verständnis von Zusammenarbeit schon immer oberste Priorität hatten.

COURAGE

Scrum Team members have courage to do the right thing and work on tough problems.
Wir haben den Mut, uns schwierigen Herausforderungen und Projekten zu stellen und dabei das Richtige für unsere Kunden zu tun.

FOCUS

Everyone focuses on the work of the Sprint and the goals of the Scrum Team.
Wir konzentrieren uns auf die Arbeit für das aktuelle Projekt und die Ziele, die unser Kunde mit diesem Projekt erreichen will.

COMMITMENT

People personally commit to achieving the goals of the Scrum Team.
Wir stehen mit unserem persönlichen Engagement für das Erreichen der gemeinsam mit unseren Kunden formulierten Projektziele ein.

RESPECT

Scrum Team members respect each other to be capable, independent people.
Unsere Arbeit basiert auf gegenseitigem Respekt und der Vision einer inklusiven Gesellschaft.

OPENESS

The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.
Wir pflegen eine offene und transparente Kommunikation mit unseren Kunden und Geschäftspartnern.

Die UNIX-Philosophie

Seit 30 Jahren entwickeln wir Software auf Grundlage der UNIX-Philosophie, wie sie Doug McIlroy bereits 1978 in einem Magazin* von Bell Systems veröffentlicht hat:

  1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
  2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
  3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
  4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

Später hat Peter H. Salus dies dann im Buch "A Quarter-Century of Unix" noch kompakter formuliert:

  • Write programs that do one thing and do it well
    Schreibe Programme die nur eine Aufgabe erledigen — diese dafür aber gut.
  • Write programs to work together
    Schreibe Programm die zusammenarbeiten.
  • Write programs to handle text streams, because that is a universal interface
    Schreibe Programme so, dass sie Textströme verarbeiten, denn dies ist eine universelle Schnittstelle.

Wer heute diese Sätze liest, mag sich vielleicht verwundert die Augen reiben — aber wirklich gute Ideen und Konzepte sind von Dauer. Oder um es gegen jede buzzwordgetriebene Marketinglogik zu formulieren: „Es gibt nichts Neues unter der Sonne.“

* "Unix Time-Sharing System: Foreword" (PDF). The Bell System Technical Journal. Bell Laboratories. pp. 1902–1903.