Innovation Games Training

In dem Interview von Jürgen Dittmar war ich voll des Lobes für sein Management 3.0 Training.

Heute möchte ich eine weitere Empfehlung für einen sehr interessanten Termin aussprechen. Die Kollegen von Scrum Events (bekannt durch die Organisation des jährlich statt findenden Scrum Days in Deutschland) haben ein Innovation Games Training am 13. und 14. Februar in Stuttgart organisiert.

Vielleicht kennen Sie die Spiele schon aus den Büchern von Luke Hohmann (Innovation Games) oder Dave Gray, Sunni Brown und James Macanufo (Gamestorming). Bei diesen Spielen handelt es sich eigentlich um Übungen, die man gut in einer Gruppe spielen kann. Während Gamestorming eine größere Sammlung von Übungen für verschiedene Anlässe ist, geht es bei den Innovation Games speziell um Kundenwünsche.

Welche Übungen kann ich mit meinen Kunden machen, um mehr über deren Anforderungen an meine Produkte zu erfahren? Product Box ist zum Beispiel eine Übung, bei der ein Team eine Schachtel so gestaltet, dass sie die Vorzüge eines neuen Produkts gut darstellt. Einerseits ist es eine schöne Alternative zum Schreiben von Market Requirements Dokumenten, weil es mehr Sinne anspricht. Andererseits ist die Übung auch lebendiger, weil jedes Team ein paar Minuten Zeit bekommt, um seine Schachtel den anderen Team werbend vorzustellen.

Wer die Innovation Games, die übrigens alle auf der Webseite (http://innovationgames.com/resources/the-games/) beschrieben sind, selbst durchspielen möchte, sollte sich schnell zum Training anmelden:http://www.scrum-events.de/zertifizierungen/certifiedinnovationgamestraining/.

PMCamp Rhein-Main 2014

Die Idee für ein PMCamp in der Nähe von Frankfurt wurde auf dem PMCamp 2012 in Dornbirn geboren. Sommer 2013 fand das erste #PMCampRM in Bad Homburg statt und war ein großer Erfolg.

Das PMCamp Rhein-Main 2014 wird vom 27. bis 28. Juni erneut in Bad Homburg stattfinden. Mehr Informationen auf der Homepage.

https://twitter.com/AgileRescue/status/422351509125607424

A better Version of the Scrum Flow diagram

As I’ll be holding a workshop about the best way to use JiraAgile with Scrum, I planned to show the “standard” Scrum Flow Chart to explain the three JiraAgile-Tabs (Plan, Work and Report). What I found missing in all of the existing Diagrams is the visualizations of the Product Owners‘ work. One could believe their sole purpose is sorting lists.

I started with a sketch of the regular flow and continued to iterate until I came to the bigger painting.

my version of the Scrum Flow Chart

The Result was a different kind of diagram than I had in mind at the start, taking the PO (and his staff) into account, while explaining some of the Ceremonies and Artifacts of a Sprint along the way. You could easily adapt it for a scaled Environment.
This “piece of art” also corresponds quite nicely with Marty Cagans’ Dual-Track-Scrum.

My final version of the Scrum Flow Chart

If you have any Ideas on how to improve this Scrum Flow Diagram, or want to know more about the art of using Jira with Scrum leave a comment below or contact me directly.

You can use this drawing freely for your trainings of workshops as long as you acknowledge me as the author ;-)

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.

(Deutsch) SAFe Big Picture 2.5

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”