Archiv der Kategorie: Overheard

Armerkater

Gefühlte zehn Jahre nach dem Start habe ich mich heute dazu entschlossen mein erstes Blog „Armerkater“ komplett offline zu nehmen.

Das Blog hat mich auf eine humorvolle Art auf einer Reise vom Projektleiter hin zum „Agile Coach“ begleitet und mir Raum gegeben mich kritisch mit populären Ideen aus dem Bereich PM & Agile auseinander zu setzen und den einen oder anderen Wahnsinn in diesen Bereich auch als solchen zu benennen.

Viele Themen sind später auch von anderen Seiten aufgegriffen worden, was für mich stets spannend war.

„Hach, stimmt. Darüber habe ich auch vor ein paar Jahren geschrieben!“ kam mir immer mal wieder in den Sinn.

Vielleicht werde ich etwas Zeit finden die eine oder andere Perle zu polieren und hier nochmal online zu stellen („Best of Armerkater“).

So sei es nun, Rest in Peace Armerkater!

 

Jeff und Ken über den neuen Scrum Guide 2016

Nach mehreren Jahren wurde der offizielle Scrum Guide aktualisiert. Die aktuelle Fassung ist hier verfügbar:

Eine wichtige Änderung im Scrum Guide 2016 sind die explizit aufgeführten Scrum Values:

  • Courage
  • Focus
  • Commitment
  • Respect
  • Openess

Die Bedeutung dieser Werte wurde/wird systematisch unterschätzt (vgl. auch Gründungstreffen der Scrum User Group Karlsruhe, 2009). Die Werte sind Teil einer Kultur, die viele kritische Aspekte von Scrum kompensiert.

Ein Beispiel hierfür ist, dass in vielen Scrum Teams sehr respektlos über nicht agilen Unternehmensteile geredet wird, obwohl diese häufig mittelfristig die tragenden Säulen der sich ändernden Organisation sind und viele gute Mitarbeiter dort ihr Bestes tun, damit die Organisation erfolgreich ist. Hier ist ein respektvoller Umgang miteinander Grundlage, um gemeinsam zu lernen und gemeinsam die Organisation weiter zu verbessern.

Wie Ken es schön zusammenfasst: Lebt man diese Werte, dann ist Scrum „ein Ort an dem Du leben möchtest“, ohne diese Werte sei Scrum „ein Ort, an dem Du nicht unbedingt sein möchtest“.

Spannend ist die Diskussion rund um den Wert „Commitment“. Ein Scrum Team „versucht nicht sein Bestes“ sondern es commitet sich auf die Dinge die im Sprint Planning als Ziel besprochen werden. Wichtig ist jedoch auch das Commitment über den Sprint hinaus – eine Verpflichtung auf die Organisation und die Zielsetzung des Vorhabens als solches. Hierzu gibt/gab es in der Vergangenheit immer wieder auch Verwirrungen.

Ein weiterer Punkt der neu aufgenommen wurde ist, dass Sprint Ziele nun Teil des Scrum Guides sind. Die bisher empfohlene Praxis ist damit zu einem „Muss“ geworden.

Das Video in dem Jeff und Ken über den neuen Scrum Guide bzw. vor allem über die Scrum Values sprechen ist bei vimeo zu finden:

Scrum Guide Refresh (July 2016) from Scrum Inc. on Vimeo.

Management 3.0 Trainer Jürgen Dittmar im Interview

Mit Management 3.0 hat Jurgen Appelo 2011 ein Buch publiziert, welches die wichtigsten Ideen eines modernen Führungsverständnisses gebündelt darstellt. Mittlerweile gibt es neben Jurgen weltweit eine ganze Reihe offizieller Management 3.0 Trainer, die dieses Seminar anbieten.

Einer dieser Trainer ist Jürgen Dittmar, der mich im September 2013 in seinem Management 3.0 Seminar begeistert hat. Jürgen ist bekannt für die Übersetzung der Kursunterlagen ins Deutsche und sicherlich einer der etabliertesten Management 3.0 Trainer im deutschsprachigen Raum.

An diese Stelle der Hinweis auf sein nächstes Seminar am 20. Januar in Frankfurt: http://www.scrum-events.de/zertifizierungen/management30/index.html. Ich selbst habe damals die Teilnahme sehr genossen und obwohl ich das Buch schon kannte eine ganze Menge Inspiration und Ideen mitnehmen können.

Jürgen Dittmar und das Management 3.0 Model
Jürgen Dittmar und das Martie, das Management 3.0 Model

So, jetzt ein paar Fragen an Jürgen.

Kannst Du Dich kurz vorstellen? Was beschäftigt Dich?

Vorstellen? O.k. hier ein paar Daten: Ich bin inzwischen 50 Jahre, verheiratet, 3 Töchter, 4 Enkelkinder und wohne in München. Ich habe Geographie, Politikwissenschaft und Arbeits- und Organisationspsychologie studiert und bin als freiberuflicher Unternehmensberater für Organisations- und Managemententwicklung insbesondere in agilen Transformationsprozessen tätig.

Dabei verstehe ich mich eigentlich als Entwicklungshelfer. Entwickeln dabei in zweierlei Hinsicht: Ich entwickle und entfessle Menschen und Organisationen. Und da sehe ich viele Fesseln, die sich Unternehmen und Menschen selbst auferlegen und nicht mehr hinterfragen.

Und was mich so beschäftigt?

Wenn ich so zurückblicke ist das bestimmende Thema in meinem Berufsleben schon immer das Thema Systeme oder “komplexe Systeme”. Zunächst als Diplom Geograph waren es die Ökosysteme in der Umweltanalyse und -planung, dann komplexe IT Systeme in meiner Zeit als Entwickler und Projektleiter und spätestens seit 12 Jahren – als ich Führungskraft und Manager wurde – das Thema Mensch und die komplexen soziale Systeme in (IT-)Organisationen und Projekten. Und das ist das was mich aktuell treibt: wie kann man wirklich Organisationen schaffen, in denen Menschen extrem motiviert, kooperativ und produktiv zusammenarbeiten. Mit Agile und Scrum als Erfolgsmodell und Basis stehen wir aus meiner Sicht da aktuell an einer Zeitenwende was das betrifft.

Management 3.0 Trainer Jürgen Dittmar im Interview weiterlesen

Alistair Cockburn über Use Cases vs User Stories

Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later.

Auszug aus einem lesenswerten Artikel („Why I still use use cases“), in dem Alistair Cockburn erklärt, warum er Use Cases für ein wertvolles Mittel zur Identifikation und Dokumentation von Anforderungen hält.

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.