Tell us about yourself, how did you get to where you are today?
This is a nice question. Now I could state it was a clear and well-planned career, but that would not be the truth. To be frank, I always got bored when a job turned out to be repetitive. I would always look for the next job where I could learn something new and try to apply this new knowledge in a different context. This brought me from starting as a software developer to a (classical) software architect, and then to a project manager.
On this path in my road, I learned that competent people and teams are the core factor for any success. So, I invested in learning additional competences – testing methods, requirements engineering, (agile) project management methods, social skills, leadership, change management – so name it. Growing older I recognized that transferring my knowledge to people and teams is very satisfying. This leads more naturally to my current profession: developing healthy teams and organizations.
You may ask: what does “healthy” mean. Well, I characterize this as the place employees like to go to work every single day.
What excites you most about Applied SAFe?
Applied SAFe is an approach and guideline to allow companies to work successfully in regulated environments. Applied SAFe makes it so it is not a daily pain to be compliant within these organizations.
What is the daily pain of a team member that is developing anything that generates value for the organization? I can tell you it’s more than filling out the work report, forms and other papers, writing useless and never read meeting minutes, and doing all the administrative activities.
Applied SAFe helps to minimize this pain while being compliant. I know, this is not what the top management likes to hear, but hey, this is what will make the organization efficient and successful. Distracting employees from value-generating activities is the real threat in any organization. The seconds most exciting aspect is that Applied SAFe offers many company-specific adoptable implementations to instantiate regulated processes within an agile context.
Can you share with us some lessons learned and advice from your experience helping companies implement agile practices?
To implement agility in a company requires bottom-up demand AND top-down support. Sustainable successful transformations always have both. I repeat, sustainable transformations. If one part is missing the organization often falls back and all the effort produced is nothing more than collateral damage.
Another lesson is, that the core statement of Ken Schwaber “inspect and adapt” is a key factor in agile transformations combined with the “Genchi genbutsu” or “go and see” principle. Agile is agile, i.e. there is no one-fits-all solution to implement agility in an organization. Even basic Scrum is different wherever you go. Team members have to agree with the implementation. Team members also must be involved in the “inspect and adapt” feedback loops to establish an accepted and active way to work.
What is the biggest myth in agile practices?
The biggest myth is that after some point in time everything will just be running smooth and fine and the system that was built is fixed and stable. This is a funny observation I made in many companies. They introduced “agile” as a project or program with the expectation of a stable and long-lasting status quo of agility.
In this case, top management missed the core of agility: The only thing that lasts forever is the change. You always have to invest in people, teams, methods, the organization, and collaboration – in the system. You always will have to face conflicts and solve them. You always have to inspect and adapt. Maybe, occasionally, the formal constraints and compliance rules around an organization are stable – what Applied SAFe insures, nevertheless inside the borders of these constraints, you have to play the inspect & adapt game.
How do you see the future of SAFe and Applied SAFe?
With every new version of SAFe, additional methods and techniques have been incorporated. The most recent move being ‘design thinking’. Design thinking itself is a rich collection and requires experience for a good adoption. If you look at SAFe today, you really have to be an experienced expert to understand all the combinations of elements. Personally, it’s hard for me to catch up with what is in there and to develop a mind model for a customer-specific context. I see the potential risk that SAFe itself might become very complex. This could result in implementation failures when guided by consultants on an advanced beginner skill level who sell themselves as experts. This already happened in the times of the rational unified process fifteen years ago. RUP itself was just fine and RUP experts generated success stories. Unluckily there were many second class implementations as well just because RUP got misunderstood by advanced beginners. So, only well-experienced agile experts understand the relationships and dependencies of the elements in SAFe and wisely select what delivers value for a company.
At PEDCO, there is a group of experts that translate SAFe into specific implementations for regulated markets. They understand the relationships and dependencies. I believe it is necessary to have Applied SAFe in every company doing SAFe. What I see as the goal of the platform is to give developers, managers, and quality departments, guidelines and blueprints on how to implement the company-specific implementation of SAFe. Having the freedom of choice is not as common in regulated environments when compared to companies that can develop its services on a low level of compliance and regulations.
Applied SAFe is made for larger organizations in regulated markets with the goal to develop services and products as agile as possible under the given constraints and regulations. Even if SAFe continues to grow and add more complexity into the framework, Applied SAFe delivers value, fosters effectiveness and efficiency by offering “Applied” guidelines and blueprints.