What SAFe does mean? I had an opportunity to attend SAFe training and find out. I was at two-day training held by Bojan Milutinović in cooperation with Agile Humans. This is the second generation of participants in the only open training in the Serbian language so far, for the official worldwide recognized certificate.
The first day, through introduction we have got the agenda of the training, Intro is very interactive and goals of attendees are very different. Through problem recognition and explanation of 5 key competencies, we’ve started SAFe map implementation.
But, first things first.
SAFe is based on three primary bodies of knowledge: Agile Development, Lean Product Development, and Systems Thinking. That makes SAFe broad, deep and scaleable. But at its core, SAFe places the highest value on four things: alignment, built-in quality, transparency, and program execution. Guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.
Alignment is needed to keep pace with fast change, disruptive competitive forces, and geographically distributed teams. While empowered, Agile Teams are good (even great), but the responsibility for strategy and alignment cannot rest with the combined opinions of the teams, no matter how good they are. Instead, alignment must rely on the Enterprise business objectives. All work is visible, debated, resolved and transparent.
Built-in Quality ensures that every element and every increment of the solution reflects quality standards throughout the development lifecycle. Quality is not “added later.” Building quality is a prerequisite of Lean and flow—without it, the organization will likely operate with large batches of unverified, unvalidated work. Excessive rework and slower velocities are likely results. Also, the bigger the system, the more important endemic quality is.
Solution development is hard. Things go wrong or do not work out as planned. Without openness, facts are obscure and decision-making is based on speculative assumptions and lack of data. No one can fix a secret. To ensure openness—trust is needed. A trust exists when the business and development can confidently rely on another to act with integrity, particularly in times of difficulty. Without trust no one can build high-performance teams and programs, nor build (or rebuild) the confidence needed to make and meet reasonable commitments. And without trust, working environments are a lot less fun and motivating. Building trust takes time.
None of the rest of SAFe matters if teams can’t execute and continuously deliver value. Therefore, SAFe places an intense focus on working systems and business outcomes. History shows us that while many enterprises start the transformation with individual Agile teams, they often become frustrated as even those teams struggle to deliver more substantial amounts of solution value, reliably and efficiently.
The second day was even more interactive. Through PI planning simulation we’ve created an experience of how this methodology can be used. PI Objectives and Iteration Goals are used to communicate expectations and commitments.
All the participants created three groups, with a specific task. The key was to align priority with other teams because the tasks were interdependent. That’s the reason why is communication between the teams so important in order to maximize efficiency.
We learned through practice, sharing opinions and conclusions. As a result, we’ve got a better understanding of why teams should planning at the same place.
In the end, a short notice about training. Very useful theory and more importantly, very useful workshops. Bojan is a very experienced trainer, with experience from different companies. He used techniques from “Training from the back of the room” which is still very rear in the training. He shared with us various practices from his personal experiences.
Overall, the training fulfilled our expectation. Very good organization and excellent trainer makes this training worth time to invest on.