In the year 2002, I started to study and apply agile thinking tools, principles, methods, and practices while working as software developer. First steps were injecting agile ideas into a small team and influence the project organization to see the benefits of implementing some aspects/ideas of Scrum and using some elements of XP to improve the engineering process and the quality of the products we were developing.

At that time I was working in Karlsruhe which is known to be one the regions where Scrum and XP have its roots in Germany. In Karlsruhe I was able to benefit from the first agile initiatives in Germany with several Scrum Trainers, Scrum Consultants, and XP experts living there and inspiring more and more companies.

With other early adopters of agile ideas, we founded „KAgile“ (Methods of agile software development Karlsruhe) in 2002. This group stopped existing after 2 years but later has found a successor in the Scrum User Group Karlsruhe which is still active today.

In 2006 I joined a medium sized company that decided to use agile concepts in the product development. At that time I was quite fluent in Scrum on the team level but still missing an official certification.

In the subsequent years I have been working occasionally as Scrum Master but soon the shift was towards being a Product Owner for developing custom solutions based on a common platform but driven by customer projects. In that role, I was sort of PO towards the team and sort of project manager towards the customer in the sense that we had limited time and resources to deliver expected outcomes. Often we had requirement specifications which we were able to „agilize“ in the sense of shifting the discussion to focus on intended outcomes instead of deliverables.

During that time the company was adopting Scrum to develop their products. This was great for the teams focusing on core product development but as we were missing any portfolio management and cross-team planning we run constantly into bottlenecks and had meetings with VP level executives for hours – every sprint.

The organization refused to plan ahead, to create a shared roadmap including critical deliveries from the project perspective backed up by teams included in the planning process. The Product Management, being part of the development group was responsible to plan the features in their products (platform) but did not take into account the needs of the projects. Following the Scrum mantra, they were pushing all responsibilities to the Project Managers – which had no power to decide anything but were the messengers that usually were slaughtered by the customer for bringing the news of additional delays and missing functionality.

During my days in that company, I saw how well paid Scrum Coaches came in and tried to implement a „Scrum by the Book“ approach without grasping the very essence of it – looking at the whole value chain not just a few (development) Scrum teams! While this approach had some positive results on the team level everything outside the development teams was in deep trouble as the „balance of power“ between roles that had a more customer-centric view and roles that had a more team-centric view was destroyed.

Looking back this sounds quite strange as the agile mindset aims to improve the relationship between customer and team instead of destroying it. Unfortunately, I saw this pattern several times in other organizations as well – agile teams losing contact with the real customer as Scrum Masters and Agile Coaches tried to „protect“ them but actually doing some local optimization.

Clearly, this setup was not working at all: Either you completely stop working on customer projects as they might inject „chaos“ into your product development organization and focus on product development only – or you had to improve customer-Dev relationship which also means to rethink the project manager role and include the project manager people in a more productive manner in the agile planning process. Additionally, it became clear that the planning process must be improved to look ahead more than one Sprint so that we all have the chance to figure out what is really valuable for the enterprise.

At this time (probably 2008/2009) I run into concepts of scaling Agile and soon I came across the work of Craig Larman/Bas Vodde as well as Dean Leffingwell.

The books written by Craig & Bas caught my attention as they are breathing an agile mindset and their idea of running experiments instead of proposing „best practices“ was resonating deeply for me. The same is true for their fantastic Large-Scale Scrum (LeSS) framework which describes some great ideas and concepts.

The books written by Dean helped me to navigate through the challenges when scaling agile development. While his early writings might not have been completely agile-minded and he was not challenging/rethinking everything from scratch it was unbelievable useful as it provided a much better overview, map or Big Picture for me at this time.

In 2012 Dean made it to the Scrum-Day conference and presented his Scaled Agile Framework in Germany for the first time. I joined his workshop and three months later the first SAFe Program Consulting training in London becoming one/the first SPCs in Germany.

Starting from that time on I was referring to the work of Dean in a way that the Scaled Agile Framework provides a great map for orientation, highlighting a lot of topics/challenges that you need to work on during an Lean-Agile transition. You then might adopt the patterns as described in the standard framework or you might need to rethink them so that they better fit your context but you will always have a handy map for orienting.

To do that successfully you need to understand the value, mindset, and principles. Unfortunately, this is something which is often skipped in many Agile, Scrum and Scaled Agile implementations. I usually try to emphasize the importance in trainings I give but often the ask is to spend more time on the practices described in the Scaled Agile Framework – and that’s probably one of the largest risks applying SAFe in your organization: Cargo Cult.

So one of the main challenges you face as coach for Lean-Agile transitions – regardless of being Scrum-based or SAFe-style – is to look out for cargo cults and try to emphasize the importance of Lean-Agile principles and values.

I’ve been working on ways of getting data out of Jira that is a actually helpful.
As you know, boards (and reports) in most tools are just views on the data that is there.
So you can combine different workflow-states in different boards to highlight interesting facts.

One of these visualisations is what I call a Cummulative FlowEfficiency Diagram (CFED).
In this Diagram I combine all the queueing states (waiting) and all the working states to see how the FlowEfficiency of the Kanban System changed over time.

The Swedes :-) The more I think about it the more I like it. What about renting a summer house in Sweden with some colleagues and then work from there. Does this also fit to the definition of #hoffice?

Agile Moves is a sustainable approach to develop and anchor new behavior and mindset during an agile transition. Agile Moves can be used on the personal level but also scaled up to larger operational units. Great work @myronymus !!!

Co-teaching Implementing SAFe class in Wiesbaden with awesome @ThorstenJanning for @kegon_ag. As usual the #scaledagile SAFe Big Picture is used actively in the class, highlighting aspects with stickies :-).