Gerade habe ich mich gefragt, wieviel Zeit man wohl damit verbringt, sich über alle Neuigkeiten seiner Facebookfreunde, Twitteranhängerschaft, der Kontakte bei Xing und linkedin sowie all der anderen interessanten Informationsquellen auf dem Laufenden zu halten. Rechnet man sämtliche Kontakte zusammen, stehe ich über die verschiedenen sozialen Netzwerke mit über 600 Personen in Verbindung, habe ich mich bei fast 100 Interessengruppen eingeschrieben und bin Mitglied in sechs Gesellschaften, Vereinen und anderen Einrichtungen. Darüber hinaus habe ich in den letzten 17 Jahren zu mehr als 1400 Leuten in relevantem E-Mail-Kontakt gestanden. Bei den nun folgenden Überlegungen werde ich bei meinen E-Mail-Kontakten eine Aktivitätsrate von fünf Prozent zugrundelegen und meine Beziehungen innerhalb der sozialen Netzwerke mit einer Quote von zehn Prozent veranschlagen. Dieses Gedankenspiel ergibt ...
Das dritte Prinzip hinter dem agilen Manifest lautet: "Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne." Was bedeutet das tatsächlich? Welche Auswirkungen hat dieses Prinzip auf unsere tägliche Arbeit? Lassen Sie uns dieses Prinzip analysieren und sehen, wohin uns das führt. "Liefere" - wir benötigen etwas fertiges, das es wert ist, einem Anwender zu geben. Werte: Mut, Commitment Prinzipien: Schnellstmöglich liefern Praktiken: Inkrementelles Deployment, Kleine Releases, Sprint Review, Produkt Demonstration "funktionierende Software" - das Ergebnis unserer Anstrengungen darf kein theoretisches Konzept oder ein Prototyp sein, sondern ein funktionierendes Software-Produkt, mit dem der Anwender effektiv arbeiten kann Werte: Focus, Commitment Prinzipien: Quality Praktiken: Definition of Done, Akzeptanz-Tests, Sprint Review, Produkt Demonstration "regelmäßig" - müssen dem Anwender ein ...
Das zweite Prinzip unter dem agilen Manifest lautet: "Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden." Was bedeutet das tatsächlich? Welche Auswirkungen hat dieses Prinzip auf unsere tägliche Arbeit? Lassen Sie uns dieses Prinzip analysieren und sehen, wohin uns das führt. "Willkommen heissen" - erzeugt ein positives und offenes Gefühl im Sinne einer Einladung. Werte: Offenheit, Respekt Prinzipien: Opportunität, Mitmenschlichkeit Praktiken: Sprint Planung, Planungsspiel "Anforderungsänderungen" - wir dürfen uns bezüglich einer Anforderung nie sicher sein, da die Realität kein statisches System ist. Menschen, Märkte, Bedürfnisse und grundsätzlich alle Dinge befinden sich in konstantem Fluß und Veränderung. Dies müssen wir in jedem einzelnen Aspekt unserer Arbeit akzeptieren und berücksichtigen. Werte: Offenheit, Mut Prinzipien: Das ...
Das erste Prinzip unter dem agilen Manifest lautet: "Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen." Was bedeutet das tatsächlich? Welche Auswirkungen hat dieses Prinzip auf unsere tägliche Arbeit? Lassen Sie uns dieses Prinzip analysieren und sehen, wohin uns das führt. "Unsere" - wer sind wir? Wir sind zumindest ein paar Leute, welche ein Team bilden. Mehr können wir aktuell nicht definieren, also schieben wir die Antwort vorerst nach hinten und analysieren ein bisschen weiter. Werte: Kommunikation Prinzipien: Vielfalt, Akzeptierte Verantwortung, Bevollmächtigtes Team Praktiken: Ganzes Team "höchste Priorität" - das Team soll nicht abgelenkt werden und seinen Fokus auf die wichtigsten Dinge legen können. Um dem Team dabei ...
Jeder, der in einem agilen Umfeld arbeitet, sollte von Zeit zu Zeit die Prinzipien hinter dem Agilen Manifest reflektieren. Was bedeuten diese Prinzipien wirklich? Welchen Einfluss haben sie auf meine tägliche Arbeit? Entsprechen meine Gepflogenheiten diesen Prinzipien? Es gibt eine schöne Übung für agile Teams, jedes dieser Prinzipien in 3 bis 4 Worten zusammenzufassen. Das Team kann darüber herausfinden, welche Essenz oder welches Detail eines jeden Prinzips für die zukünftige Zusammenarbeit wichtig ist und fokussiert werden soll. Ein agiles Team benötigt ein gemeinsames Verständnis der Prinzipien und welchen Einfluss diese auf das Verhalten des Teams haben. Ich starte eine Blog-Serie über alle zwölf agilen Prinzipien mit folgenden Zielen: Extraktion der Essenz eines jeden Prinzips Bestimmung der Werte, Praktiken und weiterer Prinzipien als Quellen eines ...
Es scheint gerade en vogue zu sein, einen neuen Blog zu beginnen, wenn man bereits einen bestehenden hat. Einige Leute in der agilen Community haben diesen Schritt in den letzten Wochen vollzogen. Vorzugsweise wechselt dabei die Blog-Sprache. Manche Leute vernachlässigen ihren deutschen Blog, um sich dem neuen englischen zu widmen. Andere stürzen sich auf ihre Muttersprache und wollen fortan auf deutsch verfassen. Zu letzterer Kategorie gehöre hiermit auch ich. Zum einen möchte ich meine primäre Zielgruppe verständlicher erreichen, zum anderen ist es in der eigenen Sprache erheblich einfacher, eine erhöhte Eloquenz an den Tag zu legen. Ich möchte nicht ausschließen, dass sich hin und wieder ein englischsprachiger Artikel in den neuen Blog einschleichen wird. Schließlich will ich mir alle Optionen offen halten, ...
The software developers in a well-known Scrum team have undergone a transition from generalists to specialists in former times. They have been responsible for no specific parts of the software system. Every developer was assigned to the next high priority tasks regardless of knowledge and experience. Combined with classical waterfall project management, solo programming, missing code reviews, and missing unit testing, the resulting quality of the system was extremely low. There was a vast lack of knowledge of the old legacy code the team was working with. To compensate that knowledge all parts of the system were assigned to specific developers - a step that turned them from generalists to specialists. Instead of moving out of the waterfall into Scrum and introducing ...
There was heavy "agile fun" in the last months with all the agilists working close with me. We made lots of wordy jokes like "the goal is the goal", "the way is the way" which became things like "way-driven driving" and nonsense like that. Thinking of all these things all the time made me come to the conclusion of a quite meaningful term I'm going to explain: the Drive-Driven Personality. "Say what? Drive-driven personality? Yup, right, c'mon, go away and never come back!" No, really and seriously. It's that easy: Drive-Driven Personality is needed to push changing the world! Many people just live their lives as is, be it private or professionally. These people may be good, valuable, hard-working thinkers with a quality above ...
Everyone getting agile has to read this book! Author: Mike Cohn Title: User Stories Applied for Agile Software Development http://bit.ly/POrak Rating: highly recommended! During any approach to implement agile procedures in an organisation there is a need to explain how management and engineering of requirements should work. Coming from traditional waterfall projects most people do not understand what those User Story stuff is all about. Usually lot of concerns are mentioned... "So, User Stories are Use Cases, right? Why don't you just call it Use Case?" "But we need all requirements at the start of our project. How should that work with User Stories?" "No, we don't need that. We know what the customers want and we know all features of the product. What for should we waste ...
Situation Many organizations do not dare to change themselves although everyone knows that things do not work well. Usually real working employees have a good feeling that things are going wrong. Unfortunately they do not have the power to trigger change but expect middle management to do so. Usually top management expects everyone to do the best job and will ask questions to middle management if things go wrong. Therefor middle management is sandwiched with expectations - this is a hard job to handle and needs explicit skills. People tend to keep an organisational status quo for several reasons: Why change anything? Never change a running system. A change would have impact on many parts of the organisation, we just can't do this. We ...
